Open Stack

Clint Byrum wrote:
> On 2013-04-30 14:52, Russell Bryant wrote:
>> My biggest concern with this is applying it to an open source project
>> with an unmanaged workforce.  Thierry captured it well when he said:
>>
>>   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.
>>
>> I'm really worried about the transition of ownership going from the
>> submitter to the project as a whole much earlier in the process.  I'd
>> like to have a high confidence level that it's worth having this code
>> for the long run before it starts coming in.  That to me requires it
>> baking out of tree and getting completed before we accept it.
> 
> What is the negative impact of having disabled code in a release? I
> think we would need a good reason before we would back accepted code
> out. If the code is just sitting there, undocumented and turned off, not
> interfering with anything, I'm having a hard time thinking of a logical
> reason to back it out.

I think the root of the problem with shipping incomplete features
disabled by default is the stable maintenance expectations. Is that
incomplete feature considered a bug in the stable branch ? The code
might be disabled, it can still be enabled... Could we mark that code in
a way that make it sufficiently clear it's not supported by the stable
branch team ? I don't really want to make it easier for CD at the
expense of the stable branch team. Or turn it into a public cloud
deployer vs. private cloud distros argument.

> The fear that somebody will drop half-baked code into the project, and
> then never return, is valid. However the impact of such a heinous act is
> mitigated by the requirement for feature flags. If the half-baked idea
> is never completed, so be it, back it out as part of normal code
> housekeeping.
> 
> Didn't this exact scenario happen with hyperV?

Not really. Hyper-V was complete when it landed (although admittedly
buggy, since code that is not tested should be considered buggy). It's
just that it wasn't maintained over time, so it broke pretty quickly
*after* that. Bad example.

A better example would be what would have happened with "Cells" if we
had switched to your model.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack