[openstack-dev] [kolla] [vote] Managing bug backports to Mitaka branch
paul.bourke at oracle.com
Thu Mar 24 09:56:25 UTC 2016
Thanks for dropping this round - I was occupied during the meeting and
wanted to be sure what I was asked to vote on! It seems like it's not a
big deal after all, also considering it's standard practice it's a no
On 24/03/16 03:55, Swapnil Kulkarni wrote:
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev