Open Stack

On Tue, 2013-04-30 at 09:04 +1200, Robert Collins wrote:
>  * Land features disabled by default. Such disabled features are
> experimental and we don't need to be so careful - we can in fact
> remove them entirely if they turn out to be bad idea - when they
> become supported (individual teams can define this we think) they
> can't be broken again though: they are now part of the product. 

I'd agree with the negative reactions to this as a blanket statement,
but I'm fine with it as one of a menu of options reviewers have when
they a large change is proposed and they want to have it land in a way
that has an acceptable level of risk for existing deployments.

You list another option - breaking the change down into smaller pieces.
Another is to give it more soak time out of tree (effectively your "no
cramming", I guess). Another is to require additional tests. Another is
to have the feature not impact existing functionality at all (like
glance v2 API, cells, GCE API, the baremetal driver).

I think nova-core has a reasonably good handle on this, but codifying
this menu of options would help people submitting patches and reviewers
on other projects.

For me, the negative reaction is about giving a license to merge crappy
unfinished code as long it's disabled by default. In reality, the
"disabled by default" approach is only a good idea if the feature is
pretty testable and if you're likely to get people to actually to go the
bother of enabling it and testing it. What we don't want is a feature
which is half-implemented, broken, nobody cares about it, those who do
try it write it off for all time so always want an option to disable it
and it never quite gets solid enough to enable by default.

Cheers,
Mark.