Open Stack

On Tue, Apr 30, 2013 at 7:58 AM, Joe Gordon <jogo at cloudscaling.com> wrote:

> On Mon, Apr 29, 2013 at 2:04 PM, Robert Collins <robertc at robertcollins.net
> > wrote:
>
>>
>>  * No more cramming: when a freeze is happening, anything that is
>> 'land this for the release' has to be pushed back on -really hard-. If
>> its not ready, it's not ready.
>>
>
> Has this been an issue recently? I thought we were getting better with
> this.
>

Agreed. Russell's introduction of a feature proposal deadline is the next
logical step in being more mature here. I don't think we need to make
specific further changes at this time.


>  * 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.
>>
>
> This touches on a bigger issue, what is experimental and what is not.
>  Currently we don't do a good job of differentiating the two.  I think we
> first need to flesh out what it means to be experimental for users and for
> development.
>

 I strongly disagree with landing features off by default. There are a few
reasons for that:

 - we've been moving away from "make it work" flags. This moves us in the
other direction -- we proliferate flags, many of which might be required to
make nova work well in real deployments. These extra flags also make the
codebase more complicated, and therefore less safe to develop in.

 - it results in untested code in the codebase (untested in the sense of
undeployed by any real deployment). This means we end up with a false sense
of security about the stability of that code until we eventually turn it on
by default. Then we discover no one has used it before and that its totally
broken.

>From my selfish upstream perspective, the purpose of CD is to help us find
errors before they hit large numbers of deployments. That's why we should
be so grateful to Rackspace, HP, or anyone else willing to run trunk --
that testing is invaluable and comes at a cost for the deployer. We should
be doing everything we can to ensure brokenness is found early, even if
that means slightly more pain for deployers.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130430/7ecf410f/attachment.html>