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