Open Stack

On 04/29/2013 08:11 PM, Michael Still wrote:
> On Tue, Apr 30, 2013 at 7:58 AM, Joe Gordon <jogo at cloudscaling.com
> <mailto:jogo at cloudscaling.com>> wrote:
>
>     On Mon, Apr 29, 2013 at 2:04 PM, Robert Collins
>     <robertc at robertcollins.net <mailto: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.

+1. If it's worth getting into the tree, it's worth coming in the front 
door working, not landing lots of untested / untestable code that's 
hidden behind a config variable from executing.

	-Sean

-- 
Sean Dague
http://dague.net