[openstack-dev] [kolla] [vote] Managing bug backports to Mitaka branch
me at coolsvap.net
Thu Mar 24 03:55:31 UTC 2016
On Thu, Mar 24, 2016 at 12:10 AM, Steven Dake (stdake) <stdake at 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. 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).
> look for timestamp 16:51:05
> From: Steven Dake <stdake at cisco.com>
> Reply-To: OpenStack Development Mailing List
> <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>
> Subject: [openstack-dev] [kolla] Managing bug backports to Mitaka branch
> Thierry (ttx in the irc log at ) 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:
> 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  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,
> copy the state of the bug, but set thte Mitaka milestone target to
> Finally they remove the rc-backport-potential tag from the bug, so it isn't
> 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  by looking at .
> 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-request at lists.openstack.org?subject:unsubscribe
I was not able to attend the meeting yesterday. I am +1 on this.
More information about the OpenStack-dev