Open Stack

On Aug 13, 2014, at 5:07 AM, Daniel P. Berrange <berrange at redhat.com> wrote:

> On Wed, Aug 13, 2014 at 12:55:48PM +0100, Steven Hardy wrote:
>> On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange wrote:
>>> On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote:
>>> By ignoring stable branches, leaving it upto a
>>> small team to handle, I think we giving the wrong message about what
>>> our priorities as a team team are. I can't help thinking this filters
>>> through to impact the way people think about their work on master.
>> 
>> Who is ignoring stable branches?  This sounds like a project specific
>> failing to me, as all experienced core reviewers should consider offering
>> their services to help with stable-maint activity.
>> 
>> I don't personally see any reason why the *entire* project core team has to
>> do this, but a subset of them should feel compelled to participate in the
>> stable-maint process, if they have sufficient time, interest and historical
>> context, it's not "some other team" IMO.
> 
> I think that stable branch review should be a key responsibility for anyone
> on the core team, not solely those few who volunteer for stable team. As
> the number of projects in openstack grows I think the idea of having a
> single stable team with rights to approve across any project is ultimately
> flawed because it doesn't scale efficiently and they don't have the same
> level of domain knowledge as the respective project teams.

This side-thread is a bit off topic for the main discussion, but as a
stable-maint with not a lot of time, I would love more help from the core
teams here. That said, help is not just about aproving reviews. There are
three main steps in the process:
 1. Bugs get marked for backport
   I try to stay on top of this in nova by following the feed of merged patches
   and marking them icehouse-backport-potential[1] when they seem like they are
   appropriate but I’m sure I miss some.
 2. Patches get backprorted
   This is sometimes a very time-consuming process, especially late in the
   cycle or for patches that are being backported 2 releases.
 3. Patches get reviewed and merged
   The criteria for a stable backport are pretty straightforward and I think
   any core reviewer is capable of understanding and aply that criteria

While we have fallen behind in number 3. at times, we are much more often WAY
behind on 2. I also suspect that a whole bunch of patches get missed in some
of the other projects where someone isn’t specifically trying to mark them all
as they come in.

Vish

[1] https://bugs.launchpad.net/nova/+bugs?field.tag=icehouse-backport-potential

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140814/40c88839/attachment.pgp>