Open Stack

On 2 Oct 2014 08:19, "Alan Pevec" <apevec at gmail.com> wrote:
>
> > 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
>
> Stable branches are maintained by the _upstream_ stable-maint team[1]
> where most members might be from (two) distros but please note that
> all PTLs are also included and there are members who are not from a
> distro.
> But you're right, if this stays mostly one distro effort, we'll pull
> out and do it on our own.
> /me looks at other non-named distros
>
> > latency there. We need to sort that out before we even consider
supporting a
> > release for more than the one year we currently do.
>
> Please consider that stable branches are also needed for the security
> fixes and we, as a responsible upstream project, need to provide that
> with or without distros. Stable branch was a master branch just few
> months ago and it inherited all the bugs present there, so everybody
> fixing a gate bug on master should consider backporting to stable at
> the same time. It can't be stable-maint-only responsiblity e.g.
> stable-maint doesn't have +2 in devstack stable/* or in tempest (now
> brancheless, so master) branches.
>
> Cheers,
> Alan
>
> [1] https://review.openstack.org/#/admin/groups/120,members
>

Hey,

When I initially proposed the concept of stable branches, it was indeed
targeted as a collaborative distro effort.

It became clear in the summit session that there was not just shared
interest from distros, but vendors and large consumers.

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.

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.

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.

I do not think it *can* now work with a small team of generalists, without
support from SME of projects.

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.

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.

I have been absent from the stable-maint effort for the last year, but have
been tracking the stable mailing list.

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.

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.

Tracking what needs to be done, allows better granular sharing of the
burden.

This is not a problem of looking at gerrit stable/* open reviews but bugs
in the process.

Is the issue mostly about changing dependencies upper versions?

Should we consider whitelisting updated dependencies in requirements.txt,
rather than blacklisting/racing to backport a fix?

Are enough patchsets proposed from current Master?

Are project core's routinely asking themselves if a patchset should be
backported?

Are we tracking open-bugs on Master well enough as also affecting stable
releases?

I do not think we are struggling primarily with technical issues, but
procedural issues.

I hope we are all agreed we /need/ something. Let's talk about 'what' and
'how', rather than 'if'.

[I will look to be more involved with stable this cycle.]

--
Kind Regards,
Dave Walker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141002/ba1c05bc/attachment.html>