Open Stack

On 2013-05-01 02:46, Thierry Carrez wrote:
> 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 ?

Definitely not. Those features are experimental, and intended for early 
adopters who are running trunk.

> 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 ?

We would definitely do well to keep a list of on-going experimental 
features. Perhaps a call in oslo.config could be used to flag 
experimental things, and then one can produce a report at release freeze 
time to enumerate the flags which have been marked experimental. We 
could even go further and introduce a warning if one turns on any 
experimental features in a tagged release.

> 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 inverse could be said too. I don't want to make it easier for 
stable branch team at the expense of CD. Neither stance is equitable, 
and thus, we should strive to find common ground which benefits both 
models and mitigates the cost of doing so. I'd like it if we all agree 
to support any deployment models which the community is willing to 
maintain, and which do not place an undue burden on opposing models.

Public vs. private clouds is not really all that relevant. What matters 
is "who" is doing the work to maintain the code and coordinate features.

>> 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.
> 

Its not a great example of landing an unfinished feature, I agree. 
However this shines some light on the false belief that a feature is 
ever "finished". The code infrastructure which HyperV was built on 
changed, and it did not. The point being, the fear that CD will somehow 
encourage this is unfounded. People will show up to maintain features if 
they need them, or people will not. When it lands and when the 
experimental tag is removed (whether by CD or stable release process) 
has very little if any bearing on what level of maintenance code will 
receive.

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

Unfortunately I did not follow that, so I cannot comment.