Re: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables
On Fri, Oct 12, 2018 at 11:44:11AM -0400, Doug Hellmann wrote: > Sean McGinnis writes: > > > [snip] > > > > One of the big motivators in the past was also to have output that > > downstream > > distros and users could pick up for testing and early packaging. Based on > > our > > admittedly anecdotal small sample, it doesn't appear this is actually a big > > need, so we propose to stop tagging milestone releases for the > > cycle-with-milestone projects. > > One of the issues that was raised from downstream consumers [1] is that > this complicates upgrade testing using packages, since tools like yum > will think that the stable branch (with a final version tag) has a > higher version number than master (with a dev version computed off of > the first release candidate where the stable branch was created). > > [snip] > > We need all projects to increment their version at least by one minor > version at the start of each cycle to save space for patch releases on > the stable branch, so we looked at a few options for triggering that > update automatically. > > [snip] > > A similarly low impact solution is to use pbr's Sem-Ver calculation > feature and inject patches into master to bump the version being > computed by 1 feature level (which should move from x.y.z.0rc1 to > somethinglike x.y+1.0.devN). See [2] for details about how this works. > > This is the approach I prefer, and I have a patch to the branching > scripts to add the Sem-Ver instruction to the patches we already > generate to update reno [3]. > > That change should take care of our transition from Stein->T, but we're > left with versions in Stein that are lower than Rocky right now. So, as > a one time operation, Sean is going to propose empty patches with the > Sem-Ver instruction in the commit message to all of the repositories for > Stein deliverables that have stable/rocky branches. > The patch to automatically propose the sem-ver flag on branching stable/* has landed and I have tested it out with our release-test repo. This seems to work well and is a much lower impact than other options we had considered. I have a set of patches queued up to now do this one-time manual step for the rocky to stein transition. **Please watch for these "empty" patches from me and get them through quickly if they look OK to you.** I have checked the list of repos to make sure none of them have done any sort off milestone release yet for stein. If you are aware of any that I have missed, please let me know. There is a strong warning with using this PBR feature that it is not obvious that having this metadata tag in the commit has this effect on a repo and it is very, very disruptive to try to undo its use. So please do not copy, backport, or do anything else with any of the commits that contain this flag. Any questions at all, please ask here or in the #openstack-release channel. Sean __ 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
Re: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables
Sean McGinnis writes: > During the Stein PTG in Denver, the release management team talked about ways > we can make things simpler and reduce the "paper pushing" work that all teams > need to do right now. One topic that came up was the usefulness of pushing > tags > around milestones during the cycle. > > There were a couple of needs identified for doing such "milestone releases": > 1) It tests the release automation machinery to identify problems before >the RC and final release crunch time. > 2) It creates a nice cadence throughout the cycle to help teams stay on >track and focus on the right things for each phase of the cycle. > 3) It gives us an indication that teams are healthy, active, and planning >to include their components in the final release. > > One of the big motivators in the past was also to have output that downstream > distros and users could pick up for testing and early packaging. Based on our > admittedly anecdotal small sample, it doesn't appear this is actually a big > need, so we propose to stop tagging milestone releases for the > cycle-with-milestone projects. One of the issues that was raised from downstream consumers [1] is that this complicates upgrade testing using packages, since tools like yum will think that the stable branch (with a final version tag) has a higher version number than master (with a dev version computed off of the first release candidate where the stable branch was created). We've discussed this problem in the past and not done anything because the downstream folks were always able to live with the gap until the first milestone. Now that we're unlikely to have milestone tags for most projects, the gap will extend to the length of the cycle, blocking upgrade testing until the release candidates are tagged, shortly before we're ready to release. They could guess at the next version numbers, but if they guess wrong they would be left with invalid packages and have to do a bunch of testing work again. It's better for us to provide authoritative information about version changes upstream. We need all projects to increment their version at least by one minor version at the start of each cycle to save space for patch releases on the stable branch, so we looked at a few options for triggering that update automatically. One option is to add a tag, like an alpha. This is somewhat appealing because the release team can just do it without anyone on the project teams having to worry about it. However, I don't particularly like this option for two reasons. First, the release team would have to monitor the work in each project and wait for some patch to land after the fork, so we could tag that (otherwise the branch would get the new version, too). More importantly, the tag would trigger a release, and I don't think we want to publish artifacts just to tweak the version calculation. A similarly low impact solution is to use pbr's Sem-Ver calculation feature and inject patches into master to bump the version being computed by 1 feature level (which should move from x.y.z.0rc1 to somethinglike x.y+1.0.devN). See [2] for details about how this works. This is the approach I prefer, and I have a patch to the branching scripts to add the Sem-Ver instruction to the patches we already generate to update reno [3]. That change should take care of our transition from Stein->T, but we're left with versions in Stein that are lower than Rocky right now. So, as a one time operation, Sean is going to propose empty patches with the Sem-Ver instruction in the commit message to all of the repositories for Stein deliverables that have stable/rocky branches. Let us know if you have any questions. Doug [1] http://lists.openstack.org/pipermail/openstack-operators/2018-October/015991.html [2] https://docs.openstack.org/pbr/latest/user/features.html#version [3] https://review.openstack.org/#/c/609827/ __ 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
Re: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables
Jeremy Stanley writes: > On 2018-09-26 09:22:30 -0500 (-0500), Sean McGinnis wrote: > [...] >> It tests the release automation machinery to identify problems >> before the RC and final release crunch time. > [...] > > More to the point, it helped spot changes to projects which made it > impossible to generate and publish their release artifacts. Coverage > has improved for finding these issues before merging now, as well as > in flight tests on proposed releases, making the risk lower than it > used to be. The new set of packaging jobs that are part of the publish-to-pypi-python3 project template also include a check queue job that runs when any of the packaging files (setup.*, README.rst, etc.) are modified. That should give us an even earlier warning of any packaging failures. Since all python projects will soon use the same release jobs, we will know that the job is working in general based on other releases (including more liberal use of our test repository before big deadlines). Doug __ 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
Re: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables
On 2018-09-26 09:22:30 -0500 (-0500), Sean McGinnis wrote: [...] > It tests the release automation machinery to identify problems > before the RC and final release crunch time. [...] More to the point, it helped spot changes to projects which made it impossible to generate and publish their release artifacts. Coverage has improved for finding these issues before merging now, as well as in flight tests on proposed releases, making the risk lower than it used to be. -- Jeremy Stanley signature.asc Description: PGP signature __ 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
[openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables
During the Stein PTG in Denver, the release management team talked about ways we can make things simpler and reduce the "paper pushing" work that all teams need to do right now. One topic that came up was the usefulness of pushing tags around milestones during the cycle. There were a couple of needs identified for doing such "milestone releases": 1) It tests the release automation machinery to identify problems before the RC and final release crunch time. 2) It creates a nice cadence throughout the cycle to help teams stay on track and focus on the right things for each phase of the cycle. 3) It gives us an indication that teams are healthy, active, and planning to include their components in the final release. One of the big motivators in the past was also to have output that downstream distros and users could pick up for testing and early packaging. Based on our admittedly anecdotal small sample, it doesn't appear this is actually a big need, so we propose to stop tagging milestone releases for the cycle-with-milestone projects. We would still have "milestones" during the cycle to facilitate work organization and create a cadence: teams should still be aware of them, and we will continue to communicate those dates in the schedule and in the release countdown emails. But you would no longer be required to request a release for each milestone. Beta releases would be optional: if teams do want to have some beta version tags before the final release they can still request them - whether on one of the milestone dates, or whenever there is the need for the project. Release candidates would still require a tag. To facilitate that step and guarantee we have a release candidate for every deliverable, the release team proposes to automatically generate a release request early in the week of the RC deadline. That patch would be used as a base to communicate with the team: if a team wants to wait for a specific patch to make it to the RC, someone from the team can -1 the patch to have it held, or update that patch with a different commit SHA. If there are no issues, ideally we would want a +1 from the PTL and/or release liaison to indicate approval, but we would also consider no negative feedback as an indicator that the automatically proposed patches without a -1 can all be approved at the end of the RC deadline week. To cover point (3) above, and clearly know that a project is healthy and should be included in the coordinated release, we are thinking of requiring a person for each team to add their name to a "manifest" of sorts for the release cycle. That "final release liaison" person would be the designated person to follow through on finishing out the releases for that team, and would be designated ahead of the final release phases. With all these changes, we would rename the cycle-with-milestones release model to something like cycle-with-rc. FAQ: Q: Does this mean I don't need to pay attention to releases any more and the release team will just take care of everything? A: No. We still want teams engaged in the release cycle and would feel much more comfortable if we get an explicit +1 from the team on any proposed tags or releases. Q: Who should sign up to be the final release liaison ? A: Anyone in the team really. Could be the PTL, the standing release liaison, or someone else stepping up to cover that role. -- Thanks! The Release Team __ 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
