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) <[email protected]> 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 <[email protected]>
Reply-To: OpenStack Development Mailing List
<[email protected]>
Date: Tuesday, March 22, 2016 at 10:12 AM
To: OpenStack Development Mailing List <[email protected]>
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: [email protected]?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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
