Preparing for 2013.1.1 stable/grizzly WAS Proposed stable/grizzly release dates
Hello fellow stable maintainers
2013/4/8 Mark McLoughlin markmc@redhat.com: ...
There's going to be a design summit session on stable branch processes ... that's a good time for us to revisit what we're doing and discuss in detail.
So there was a session, notes are in etherpad [1]
Adam Gandelman (adam_g on irc) and Alan Pevec (apevec on irc) will take over, in turns, managing stable/grizzly releases from markmc.
Adam, please join this list http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint I've added you to openstack-stable-maint in Gerrit, welcome to the team!
First stable/grizzly release 2013.1.1 is planned for May 9 - early release to pick up critical Grizzly fixes as suggested by Daviey. That puts stable freeze date on May 2, which is already next week!
There are 28 open bugs tagged grizzly-backport-potential [2] out of that 14 have a patch (status In progress).
There are 20-something open stable/grizzly reviews in Gerrit [3] Already merged backports are: 14 Nova, 9 Quantum, 8 Cinder, 1 Horizon, 1 Keystone and 1 Ceilometer. BTW last one is an Integrated OpenStack Project with DIY stable branch - https://wiki.openstack.org/wiki/StableBranch policy covers only core projects.
I'd like to ask all PTLs to have a look at open bugs in their respective projects and tell us which bugs they think are critical and should be included in the first stable/grizzly release. Are there more bugs which are critical but missing grizzly-backport-potential tag?
Everybody should be reviewing and proposing new backports for stable/grizzly in Gerrit now while we still have time to avoid last-minute crunch before the freeze. Once again, freeze is planned for Thursday, May 2nd.
On the bitrot jobs front, I only see Networking failing randomly with "Build timed out (after 30 minutes)" [4] mark.mcclain, garyk, any ideas?
Finally, future stable/grizzly releases will be: 2013.1.2 Jun 6 - managed by adam_g 2013.1.3 Aug 8 - apevec 2013.1.4 Oct 10 - adam_g 2013.1.5 - last planned, date TBD, after H release, apevec
Cheers, Alan
[1] https://etherpad.openstack.org/havana-stable-branch
[2] https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.stat...
[3] https://review.openstack.org/#/q/status:open+branch:stable/grizzly,n,z
[4] https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/
On 04/22/2013 02:57 PM, Alan Pevec wrote:
So there was a session, notes are in etherpad [1]
Adam Gandelman (adam_g on irc) and Alan Pevec (apevec on irc) will take over, in turns, managing stable/grizzly releases from markmc.
Adam, please join this list http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint I've added you to openstack-stable-maint in Gerrit, welcome to the team!
First stable/grizzly release 2013.1.1 is planned for May 9 - early release to pick up critical Grizzly fixes as suggested by Daviey. That puts stable freeze date on May 2, which is already next week!
There are 28 open bugs tagged grizzly-backport-potential [2] out of that 14 have a patch (status In progress).
Hi Alan-
Thanks for the follow up and adding me to the team. I've been looking through the bug and patch queues and had a couple of questions:
- The LP search you linked to only contains bugs with open tasks. Adding 'Fix Committed' [1] shows many more that are tagged, fixed in project's master but not proposed to stable/grizzly. I assume we should also make sure these get tracked as well? I see a few relatively small patches that seem suitable for stable backport, eg [2]
- Should core-devs/PTLs be nominating bugs as affecting Grizzly before someone else proposes a backport? Or are we only looking for tags? I couldn't grok the importance of bug tasks / nominations from the wiki. Based on experiences elsewhere in the LP/Ubuntu world, I had assumed a Confirmed bug nomination against Grizzly is confirmation from PTL/core-dev that the fix is suitable for backporting to stable.
Thanks again, Adam
[1] https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.stat...
I can't say for sure if other projects follow this but generally I tag each bug report with grizzly-backport-potential. When I go to do the backport I remove the tag and target it to the grizzly series and propose it. If the back port itself is tricky, I sometimes ask the original author to do it.
Vish On Apr 24, 2013 12:40 AM, "Adam Gandelman" adamg@canonical.com wrote:
On 04/22/2013 02:57 PM, Alan Pevec wrote:
So there was a session, notes are in etherpad [1]
Adam Gandelman (adam_g on irc) and Alan Pevec (apevec on irc) will take over, in turns, managing stable/grizzly releases from markmc.
Adam, please join this list http://lists.openstack.org/**cgi-bin/mailman/listinfo/** openstack-stable-mainthttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint I've added you to openstack-stable-maint in Gerrit, welcome to the team!
First stable/grizzly release 2013.1.1 is planned for May 9 - early release to pick up critical Grizzly fixes as suggested by Daviey. That puts stable freeze date on May 2, which is already next week!
There are 28 open bugs tagged grizzly-backport-potential [2] out of that 14 have a patch (status In progress).
Hi Alan-
Thanks for the follow up and adding me to the team. I've been looking through the bug and patch queues and had a couple of questions:
- The LP search you linked to only contains bugs with open tasks. Adding
'Fix Committed' [1] shows many more that are tagged, fixed in project's master but not proposed to stable/grizzly. I assume we should also make sure these get tracked as well? I see a few relatively small patches that seem suitable for stable backport, eg [2]
- Should core-devs/PTLs be nominating bugs as affecting Grizzly before
someone else proposes a backport? Or are we only looking for tags? I couldn't grok the importance of bug tasks / nominations from the wiki. Based on experiences elsewhere in the LP/Ubuntu world, I had assumed a Confirmed bug nomination against Grizzly is confirmation from PTL/core-dev that the fix is suitable for backporting to stable.
Thanks again, Adam
[1] https://bugs.launchpad.net/**bugs/+bugs?field.status%** 3Alist=NEW&field.status%**3Alist=FIXCOMMITTED&field.** status%3Alist=CONFIRMED&field.**status%3Alist=TRIAGED&field.** status%3Alist=INPROGRESS&**field.status%3Alist=**INCOMPLETE_WITH_RESPONSE& **field.status%3Alist=**INCOMPLETE_WITHOUT_RESPONSE&**field.status%3Alist= **FIXCOMMITTED&field.tag=**grizzly-backport-potential&** field.tags_combinator=ANY&**search=Search&orderby=-id&**start=0https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=FIXCOMMITTED&field.tag=grizzly-backport-potential&field.tags_combinator=ANY&search=Search&orderby=-id&start=0
[2] https://bugs.launchpad.net/**keystone/+bug/1125637https://bugs.launchpad.net/keystone/+bug/1125637
______________________________**_________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.**openstack.orgOpenstack-stable-maint@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/** openstack-stable-mainthttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
On Wed, Apr 24, 2013 at 8:30 AM, Vishvananda Ishaya vishvananda@gmail.comwrote:
I can't say for sure if other projects follow this but generally I tag each bug report with grizzly-backport-potential. When I go to do the backport I remove the tag and target it to the grizzly series and propose it. If the back port itself is tricky, I sometimes ask the original author to do it.
Vish
I've been following the process Vish described in Cinder as well.
On Apr 24, 2013 12:40 AM, "Adam Gandelman" adamg@canonical.com wrote:
On 04/22/2013 02:57 PM, Alan Pevec wrote:
So there was a session, notes are in etherpad [1]
Adam Gandelman (adam_g on irc) and Alan Pevec (apevec on irc) will take over, in turns, managing stable/grizzly releases from markmc.
Adam, please join this list http://lists.openstack.org/**cgi-bin/mailman/listinfo/** openstack-stable-mainthttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint I've added you to openstack-stable-maint in Gerrit, welcome to the team!
First stable/grizzly release 2013.1.1 is planned for May 9 - early release to pick up critical Grizzly fixes as suggested by Daviey. That puts stable freeze date on May 2, which is already next week!
There are 28 open bugs tagged grizzly-backport-potential [2] out of that 14 have a patch (status In progress).
Hi Alan-
Thanks for the follow up and adding me to the team. I've been looking through the bug and patch queues and had a couple of questions:
- The LP search you linked to only contains bugs with open tasks. Adding
'Fix Committed' [1] shows many more that are tagged, fixed in project's master but not proposed to stable/grizzly. I assume we should also make sure these get tracked as well? I see a few relatively small patches that seem suitable for stable backport, eg [2]
- Should core-devs/PTLs be nominating bugs as affecting Grizzly before
someone else proposes a backport? Or are we only looking for tags? I couldn't grok the importance of bug tasks / nominations from the wiki. Based on experiences elsewhere in the LP/Ubuntu world, I had assumed a Confirmed bug nomination against Grizzly is confirmation from PTL/core-dev that the fix is suitable for backporting to stable.
Thanks again, Adam
[1] https://bugs.launchpad.net/**bugs/+bugs?field.status%** 3Alist=NEW&field.status%**3Alist=FIXCOMMITTED&field.** status%3Alist=CONFIRMED&field.**status%3Alist=TRIAGED&field.** status%3Alist=INPROGRESS&**field.status%3Alist=** INCOMPLETE_WITH_RESPONSE&**field.status%3Alist=** INCOMPLETE_WITHOUT_RESPONSE&**field.status%3Alist=** FIXCOMMITTED&field.tag=**grizzly-backport-potential&** field.tags_combinator=ANY&**search=Search&orderby=-id&**start=0https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=FIXCOMMITTED&field.tag=grizzly-backport-potential&field.tags_combinator=ANY&search=Search&orderby=-id&start=0
[2] https://bugs.launchpad.net/**keystone/+bug/1125637https://bugs.launchpad.net/keystone/+bug/1125637
______________________________**_________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.**openstack.orgOpenstack-stable-maint@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/** openstack-stable-mainthttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
On 04/24/2013 06:03 PM, John Griffith wrote:
On Wed, Apr 24, 2013 at 8:30 AM, Vishvananda Ishaya <vishvananda@gmail.com mailto:vishvananda@gmail.com> wrote:
I can't say for sure if other projects follow this but generally I tag each bug report with grizzly-backport-potential. When I go to do the backport I remove the tag and target it to the grizzly series and propose it. If the back port itself is tricky, I sometimes ask the original author to do it. VishI've been following the process Vish described in Cinder as well.
In Quantum I do practically the same. I only remove the tag when the patch has been approved (makes it easier to track).
On Apr 24, 2013 12:40 AM, "Adam Gandelman" <adamg@canonical.com <mailto:adamg@canonical.com>> wrote: On 04/22/2013 02:57 PM, Alan Pevec wrote: So there was a session, notes are in etherpad [1] Adam Gandelman (adam_g on irc) and Alan Pevec (apevec on irc) will take over, in turns, managing stable/grizzly releases from markmc. Adam, please join this list http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint I've added you to openstack-stable-maint in Gerrit, welcome to the team! First stable/grizzly release 2013.1.1 is planned for May 9 - early release to pick up critical Grizzly fixes as suggested by Daviey. That puts stable freeze date on May 2, which is already next week! There are 28 open bugs tagged grizzly-backport-potential [2] out of that 14 have a patch (status In progress). Hi Alan- Thanks for the follow up and adding me to the team. I've been looking through the bug and patch queues and had a couple of questions: - The LP search you linked to only contains bugs with open tasks. Adding 'Fix Committed' [1] shows many more that are tagged, fixed in project's master but not proposed to stable/grizzly. I assume we should also make sure these get tracked as well? I see a few relatively small patches that seem suitable for stable backport, eg [2] - Should core-devs/PTLs be nominating bugs as affecting Grizzly before someone else proposes a backport? Or are we only looking for tags? I couldn't grok the importance of bug tasks / nominations from the wiki. Based on experiences elsewhere in the LP/Ubuntu world, I had assumed a Confirmed bug nomination against Grizzly is confirmation from PTL/core-dev that the fix is suitable for backporting to stable. Thanks again, Adam [1] https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=FIXCOMMITTED&field.tag=grizzly-backport-potential&field.tags_combinator=ANY&search=Search&orderby=-id&start=0 <https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=FIXCOMMITTED&field.tag=grizzly-backport-potential&field.tags_combinator=ANY&search=Search&orderby=-id&start=0> [2] https://bugs.launchpad.net/keystone/+bug/1125637 _______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org <mailto:Openstack-stable-maint@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint _______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org <mailto:Openstack-stable-maint@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
Hi Adam,
- The LP search you linked to only contains bugs with open tasks. Adding
'Fix Committed' [1] shows many more that are tagged, fixed in project's master but not proposed to stable/grizzly. I assume we should also make sure these get tracked as well?
Yes, part of the stable release process[1] to identify all bugs with patches committed to the stable branch and target them to Grizzly series in Launchpad.
I see a few relatively small patches that seem suitable for stable backport, eg [2]
Yep, that one certainly is a good stable candidate.
- Should core-devs/PTLs be nominating bugs as affecting Grizzly before
someone else proposes a backport? Or are we only looking for tags?
As others replied, both tags and target series are useful when preparing backports, but eventually tags are stripped and all fixed bugs must target series and milestone, so that they show up on the milestone Launchpad page.
Cheers, Alan
participants (5)
-
Adam Gandelman
-
Alan Pevec
-
Gary Kotton
-
John Griffith
-
Vishvananda Ishaya