Open Stack

On 3 March 2016 at 13:10, Markus Zoeller <mzoeller at de.ibm.com> wrote:
> We have now 11-15 days left [1] until it is planned to release the first
> release candidate. To provide a stable release, we need to identify the
> potential release blockers. Bugs which potentially block the release
> should be tagged with "mitaka-rc-potential". They can then be queried in
> Launchpad with [2].
>
> Agreed on blockers will get the "mitaka-rc1" milestone in Launchpad and
> are queryable with [3]. Because the next Nova meeting at March 10th
> could be to close to RC1 to decide actionable items, bring those
> potentials to the attention on the ML or in #openstack-nova.
>
> Open patches for blocker bugs can be queried with the script
> "query_rc_blockers.py" from [4]. The tags will be kept on the bug reports
> in case we will release additional RCs.
>
> When the final release is done we can remove the "mitaka-rc-potential"
> tag from the open bug reports. Probably it makes sense to increase their
> importance to "high" after that to put some focus on them for the
> Newton cycle. Open patches for high|critical bugs can be queried with
> "query_high_prio_bug_fixes.py" from [4].
>
> I recommend to the subteams to go through the bug reports of their area
> and double-check them if there are blockers. Please also spent some
> effort to go through the list of "new" bug reports [5]. There weren't
> enough volunteers for the bug skimming duty in the last months to get
> this list to zero.
>
> References:
> [1] http://releases.openstack.org/mitaka/schedule.html#m-rc1
> [2] https://bugs.launchpad.net/nova/+bugs?field.tag=mitaka-rc-potential
> [3] https://launchpad.net/nova/+milestone/mitaka-rc1
> [4]
> https://github.com/markuszoeller/openstack/tree/master/scripts/launchpad
> [5] https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New

Point of clarification...

In nova we are only using "mitaka-rc-potential" to track possible bugs
might block/delay RC1. You are not required to add this tag before
merging a bug fix.

Having said that, the normal rules apply for this point in the cycle.
Reviewers should reject patches that are likely to damage the quality
of the release, due to a big regression risk, breaking the soft string
freeze, etc.

As always, any questions, please ask,
johnthetubaguy