[openstack-dev] Continuous deployment - significant process change
robertc at robertcollins.net
Tue Apr 30 01:18:50 UTC 2013
On 30 April 2013 10:48, Russell Bryant <rbryant at redhat.com> wrote:
> I think you can develop a feature in its entirety with a series of
> reasonably sized changes with a well designed patch set.
> Once code gets in to the tree, it becomes a burden on the project to
> maintain that code, even if disabled by default. If your feature isn't
> done, I don't want it in the tree.
Lets separate out some concerns here.
- pushing crap code, or code prematurely
- waiting for a feature to be 'finished' before landing it.
The former is a scary risk, and not something I want to see.
The latter is - I put it to you - impossible. A -big chunk- of the
reason for a freeze is because we recognize that features that are
landing today are *not done*. They are *not finished*. The model of
'build a chunk of work and then when you're really happy land it' has
a tonne of friction - moving dependencies, interactions with other
changes, and the difficulties of production hardening - that make it a
dream, not the actual reality.
Lets look at what is being proposed in detail as a delta against our
current published standards:
- A single conceptual change would be allowed to land if it passes
review, *even if it has no callers in the code base yet*.
- Features that are building up towards completeness would have their
code disabled by default, to prevent accidental impact on users.
- As a consequence most new features would be able to be easily
*disabled* upon release, in the event of issues.
There is a related discussion, about the interaction between freezes
and cramming, but I know that folk that haven't experienced the CD
workflow and the qualitative change it brings will be very hesitant to
embrace it, so I think we should leave that for the next cycle when
the basics are in place.
Robert Collins <rbtcollins at hp.com>
HP Cloud Services
More information about the OpenStack-dev