Open Stack

Michael Still wrote:
> I agree with Sean here.
> 
> The original idea was that these stable branches would be maintained by
> the distros, and that is clearly not happening if you look at the code
> review latency there. We need to sort that out before we even consider
> supporting a release for more than the one year we currently do.

Well, it's just another area where the current model fails to scale.
It's easy to only talk about gating and release management and overlook
vulnerability management, stable maintenance and other horizontal tasks
where the resources also don't grow nearly as fast as new integrated
projects and complexity.

As far as stable is concerned, the fix is relatively simple and has been
proposed a while back: push responsibility of stable branch maintenance
down at project-level. The current stable-maint team would become
"stable branch release managers" and it would be the responsibility of
each project to maintain their stable branch, backport fixes and making
sure things can get merged to it.

Those projects may or may not be willing to commit to 15 months
maintenance (which means maintaining 2-3 stable branches in addition to
master). But I think what they can commit to is a better reflection of
what we can achieve -- since without upstream support it's difficult to
keep all stable branches for all integrated projects alive.

I already planned to dedicate a cross-project workshop (or a release
management scheduled slot) to that specific topic, so that we can have a
clear way forward in Kilo.

-- 
Thierry Carrez (ttx)