Hi folks, 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: 1. Any individual may propose a newton bug for backport potential by specifying the tag 'rc-backport-potential" in the Newton 1 milestone. 2. 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: 1. Allow the core reviewer team to keep track of bugs needing attention for the release candidates in [2] by looking at [3]. 2. Allow master development to proceed un-impeded. 3. 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. Regards, -steve [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2016-03-22.log.html#t2016-03-22T16:23:11 [2] https://launchpad.net/kolla/+milestone/mitaka-rc2 [3] https://bugs.launchpad.net/kolla/+bugs?field.tag=rc-backport-potential
__________________________________________________________________________ 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
