Open Stack

On 30 April 2013 10:48, Russell Bryant <rbryant at redhat.com> wrote:

>>
>> http://rc3.org/2013/03/03/dont-get-stuck/
>
> 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.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services