[openstack-dev] Continuous deployment - significant process change
sean at dague.net
Tue Apr 30 00:53:44 UTC 2013
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.
More information about the OpenStack-dev