Open Stack

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 ?

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 ?

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

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 ?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack