On Thu, Mar 24, 2016 at 12:10 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > 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 <std...@cisco.com> > Reply-To: OpenStack Development Mailing List > <openstack-dev@lists.openstack.org> > Date: Tuesday, March 22, 2016 at 10:12 AM > To: OpenStack Development Mailing List <openstack-dev@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: > > Any individual may propose a newton bug for backport potential by specifying > the tag 'rc-backport-potential" in the Newton 1 milestone. > 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: > > Allow the core reviewer team to keep track of bugs needing attention for the > release candidates in [2] by looking at [3]. > Allow master development to proceed un-impeded. > 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. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
I was not able to attend the meeting yesterday. I am +1 on this. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
