Open Stack

Robert Collins wrote:
> [...]
> But to answer your points:
>  - an unreleased feature is an unreleased feature irrespective of what
> branch it is in. It's not something you'd pull bug fixes into a frozen
> branch for.
>  - If the codebase knows it's a release branch (can we tell
> programmatically?) we could just refuse to enable unreleased features.

The codebase used to be able to tell (Final=True) but with our
tag-driven process it no longer can. That said I don't think it needs
to. A generic use_experimental_features_OMG_DONT_DO_THAT_OH_FOOL flag
could be used in all branches (defaulting to False).

> I understand your concerns about making it easier for one group vs
> another - I don't think this is a zero-sum game. CD disciplines make
> code evolution faster and safer for /everyone/.

I'm totally convinced it's not a zero-sum game. Personally I think we
need a pretty awesome framework to handle experimental configuration
options, one that would make sure you know what you're doing (and the
consequences of doing so) when you enable one. We also need to be able
to tell (from a stable maintenance / vulnerability management
perspective) if code is experimental or not, and manage its lifecycle
easily (transition from experimental to supported or dead).

If that is achieved, the consequences for the user and for the
maintenance teams are limited and probably make it a good trade-off.

> [...]
> The key bad outcomes folk want to see addressed are:
>  - The project owning lots of incomplete useless code
>  - Bugs being introduced
>  - Documentation and user support burdens being increased
>  - Conf file setting proliferation [with backwards compat constraints
> on removals]
>  - Stable branch maintenance becoming harder.

I didn't see where your proposal addresses the "project owning lots of
incomplete useless code" bad outcome. I suspect it would not just be
"incomplete useless code", but also "always experimental code": stuff
that lives in experimental, kinda works, but nobody polishes it or has
the guts to remove it (after all, it kinda works). You have to track
that and solve it somehow.

I suspect this (which I called "experimental feature lifecycle" above)
puts extra tracking effort on PTLs (and ultimately the release manager).
We don't really want extra effort... Ideas ?

-- 
Thierry Carrez (ttx)