<p dir="ltr"><br>
On 2 Oct 2014 08:19, "Alan Pevec" <<a href="mailto:apevec@gmail.com">apevec@gmail.com</a>> wrote:<br>
><br>
> > The original idea was that these stable branches would be maintained by the<br>
> > distros, and that is clearly not happening if you look at the code review<br>
><br>
> Stable branches are maintained by the _upstream_ stable-maint team[1]<br>
> where most members might be from (two) distros but please note that<br>
> all PTLs are also included and there are members who are not from a<br>
> distro.<br>
> But you're right, if this stays mostly one distro effort, we'll pull<br>
> out and do it on our own.<br>
> /me looks at other non-named distros<br>
><br>
> > latency there. We need to sort that out before we even consider supporting a<br>
> > release for more than the one year we currently do.<br>
><br>
> Please consider that stable branches are also needed for the security<br>
> fixes and we, as a responsible upstream project, need to provide that<br>
> with or without distros. Stable branch was a master branch just few<br>
> months ago and it inherited all the bugs present there, so everybody<br>
> fixing a gate bug on master should consider backporting to stable at<br>
> the same time. It can't be stable-maint-only responsiblity e.g.<br>
> stable-maint doesn't have +2 in devstack stable/* or in tempest (now<br>
> brancheless, so master) branches.<br>
><br>
> Cheers,<br>
> Alan<br>
><br>
> [1] <a href="https://review.openstack.org/#/admin/groups/120,members">https://review.openstack.org/#/admin/groups/120,members</a><br>
></p>
<p dir="ltr">Hey,</p>
<p dir="ltr">When I initially proposed the concept of stable branches, it was indeed targeted as a collaborative distro effort.</p>
<p dir="ltr">It became clear in the summit session that there was not just shared interest from distros, but vendors and large consumers.</p>
<p dir="ltr">It was /not/ something that I envisaged would become a project responsibility, just an area for the various types of consumer to collaborate, rather than duplicating effort in downstreams.. Most likely missing pretty important stability patches.</p>
<p dir="ltr">I didn't want dedicated point releases, just an always stable area where consumers could pull/rebase from. This idea pretty much changed, and vendors wanted a stamped-point release to make the situation clearer to their users.</p>
<p dir="ltr">I think everyone would agree that the project and scope has grown pretty significantly since the early days, and I agree that there does need to be project-wide share of the burden of keeping the stable branches maintained, with stable-maint becoming the driver. It can only scale if there is sustained interest from each project.</p>
<p dir="ltr">I do not think it *can* now work with a small team of generalists, without support from SME of projects.</p>
<p dir="ltr">I am pretty nervous of the point you make about Red Hat taking their ball and going home if more distros don't commit to more effort. This is pretty simply not the way to encourage more participation.</p>
<p dir="ltr">Sadly, the git pull stats cannot be public.. But I am pretty sure that a reasonably large consumer-base slurp up the branches directly. If this is true, then it is clear that the project has a responsibility to users.. Therefore, the quick fire point of talking about stable branch ongoing feasibility is a bit rash.  The general project clearly isn't ready for rolling release, so we need to talk about how we can make this work.</p>
<p dir="ltr">I have been absent from the stable-maint effort for the last year, but have been tracking the stable mailing list.</p>
<p dir="ltr">This feels like the first credible 'we are struggling' that has been raised - I actually believed it was reasonably healthy. It does seem that this issue has been brewing for a while.</p>
<p dir="ltr">Therefore, I think we need to do a better effort of tracking weak areas in the process. We do not have a decent TODO list.</p>
<p dir="ltr">Tracking what needs to be done, allows better granular sharing of the burden.</p>
<p dir="ltr">This is not a problem of looking at gerrit stable/* open reviews but bugs in the process.</p>
<p dir="ltr">Is the issue mostly about changing dependencies upper versions? </p>
<p dir="ltr">Should we consider whitelisting updated dependencies in requirements.txt, rather than blacklisting/racing to backport a fix?</p>
<p dir="ltr">Are enough patchsets proposed from current Master?</p>
<p dir="ltr">Are project core's routinely asking themselves if a patchset should be backported?</p>
<p dir="ltr">Are we tracking open-bugs on Master well enough as also affecting stable releases?</p>
<p dir="ltr">I do not think we are struggling primarily with technical issues, but procedural issues.</p>
<p dir="ltr">I hope we are all agreed we /need/ something. Let's talk about 'what' and 'how', rather than 'if'.</p>
<p dir="ltr">[I will look to be more involved with stable this cycle.]</p>
<p dir="ltr">--<br>
Kind Regards,<br>
Dave Walker</p>