Open Stack

Hey Steve,

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 
brainer. +1

Cheers,
-Paul

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[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>
>> 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 [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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>