Open Stack

We had an emergency voting session on this proposal on IRC in our team meeting today and it passed as documented in the meeting minutes[1].  I was asked to have a typical vote and discussion on irc by one of the participants of the vote, so please feel free to discuss and vote again.  I will leave discussion and voting open until March 30th.  If the voting is unanimous prior to that time, I will close voting.  The original vote will stand unless there is a majority that oppose this process in this formal vote.  (formal votes > informal irc meeting votes).

Thanks,
-steve

[1] http://eavesdrop.openstack.org/meetings/kolla/2016/kolla.2016-03-23-16.30.log.html

look for timestamp 16:51:05

From: Steven Dake <stdake at cisco.com<mailto:stdake at cisco.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, March 22, 2016 at 10:12 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [kolla] Managing bug backports to Mitaka branch

Thierry (ttx in the irc log at [1]) proposed the standard way projects typically handle backports of newton fixes that should be fixed in an rc, while also maintaining the information in our rc2/rc3 trackers.

Here is an example bug with the process applied:
https://bugs.launchpad.net/kolla/+bug/1540234

To apply this process, the following happens:

  1.  Any individual may propose a newton bug for backport potential by specifying the tag 'rc-backport-potential" in the Newton 1 milestone.
  2.  Core reviewers review the rc-backport-potential bugs.
     *   CR's review [3] on a daily basis for new rc backport candidates.
     *   If the core reviewer thinks the bug should be backported to stable/mitaka, (or belongs in the rc), they use the Target to series button, select mitaka, save.
     *    copy the state of the bug, but set thte Mitaka milestone target to "mitaka-rc2".
     *   Finally they remove the rc-backport-potential tag from the bug, so it isn't re-reviwed.

The purpose of this proposal is to do the following:

  1.  Allow the core reviewer team to keep track of bugs needing attention for the release candidates in [2] by looking at [3].
  2.  Allow master development to proceed un-impeded.
  3.  Not single thread on any individual for backporting.

I'd like further discussion on this proposal at our Wednesday meeting, so I've blocked off a 20 minute timebox for this topic.  I'd like wide agreement from the core reviewers to follow this best practice, or alternately lets come up with a plan b :)

If your a core reviewer and won't be able to make our next meeting, please respond on this thread with your  thoughts.  Lets also not apply the process until the conclusion of the discussion at Wednesday's meeting.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160323/2d66a1c3/attachment.html>