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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
