Open Stack

On 2013-05-02 03:19, Thierry Carrez wrote:
> Clint Byrum wrote:
>> On 2013-05-01 02:46, Thierry Carrez wrote:
>>> 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.
> 
> So, if a promised feature ends up not being "completed" by feature
> freeze, your suggestion would be to keep it in as "experimental", or 
> to
> remove it ?
> 

Keep it.

> I now think you mean the former, but in the case you mean the latter,
> what do you think of my suggestion to only allow incremental feature
> landing up until a given point in the release cycle (havana-2 ?) to 
> give
> us extra time to remove the incomplete bits before release ?
> 

The removal would be all pain for almost no gain. In fact, I would 
think that the stable maintenance team would appreciate that the code is 
more like trunk when they have to backport patches in areas adjacent to 
experimental code paths. The inverse is true too (if the experimental 
bit has been made the default, then they'll have more burden). But I 
think we can expect this to be at worst a tie in terms of maintenance 
burden.

>> 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.
> 
> FTR, I'm not opposed to this as long as we somehow solve the user
> expectations issue ("bugs in experimental/incomplete features are to 
> be
> expected and not fixed"). But I don't think this policy can be 
> mandated,
> it has to be accepted by PTLs and review teams in the various 
> projects.
> For this to work, project people need to be convinced that it's the
> right trade-off.
> 

Agreed. Thats what we're doing here, trying to get everyone on board 
with the idea.

> Maybe one (convinced) project could play with that (in the same way
> Keystone played with feature branches while working on v3) and push 
> some
> features for marking parts of the code incomplete/experimental into 
> Oslo ?

Yes, oslo.config would be the place for an experimental config control 
facility.