Open Stack

> From: Thierry Carrez [mailto:thierry at openstack.org]
> 
> Robert Collins wrote:

: <snip>

> >  * 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.
> 
> That's the most controversial part. You make a good case of how this is
> easier than the "collection of relatively-small patchsets" approach, and
> potentially better for CD (I'm still not totally convinced that
> switching a full feature ON at some point rather than landing
> incremental patchsets is less disruptive for CD, but you know that stuff
> better than I do).
> 
> Personally my experience of OpenStack project management makes me fear
> that your proposal ignores the reality of our unmanaged development
> workforce: there is no way we can be sure that a feature will actually
> be completed. So you might end up having disabled code in releases... or
> force the removal of the already-landed parts at the very last moment,
> which is disruptive to release quality and also sounds more disruptive
> to CD than what you are trying to protect against.
> 
> One intermediary approach could be that this kind of disabled features
> need to be enabled by ~havana-2, to give us plenty of time to remove
> them before havana-3 if they are not complete... Additional benefits
> being that those "large features" land in the middle of the cycle rather
> than at the very end.
> 

I think the main concern for those using trunk in their production environments would be that they have the ability to choose not to run a new feature.  This does not prescribe whether that feature is on or off by default.

If there is no way to turn a feature off, and a consumer of trunk does not want to run that feature in their production environment, then the only option would be to stop running trunk in production until either the feature is more stable/configurable/removed.  This then removes the benefit of the production scale testing of the code that the consumer had previously been providing to Openstack by running trunk in their production environment.

: <snip>

> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks, 
Jon-Paul Sullivan ☺ Cloud Services - @hpcloud

Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway.
Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. 
Registered Number: 361933
 
The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender.

To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as "HP CONFIDENTIAL".