Hi everyone, On Tuesday afternoon of the PTG week we had a track of discussions to brainstorm how to better align our release cycle and stable branch maintenance with the OpenStack downstream consumption models.
You can find the notes at: https://etherpad.openstack.org/p/release-cycles-ptg-rocky TL;DR: summary: * No consensus on longer / shorter release cycles * Focus on FFU to make upgrades less painful * Longer stable branch maintenance time (18 months for Ocata) * Bootstrap the "extended maintenance" concept with common policy * Group most impacted by release cadence are packagers/distros/vendors * Need for finer user survey questions on upgrade models * Need more data and more discussion, next discussion at Vancouver forum * Release Management team tracks it between events Details: We started the discussion by establishing a taxonomy of consumption models and upgrade patterns. This exercise showed that we are lacking good data on how many people follow which. The user survey asks what people are using to deploy and what they are running, but the questions are a bit too simple (some deploys have a mix of versions, what should they answer) or incomplete (some deployment mechanisms combine high-level and low-level packaging). It also misses the question of the upgrade pattern completely. I took the action of circling back with the user survey folks to see if we could enrich (or add to) those questions in the future. Another point of data, Swift seems to be the only component with an established pattern of upgrading at every intermediary release (as opposed to random points on master, or every final release). It is probably due to it being consumed standalone more than others. We continued by discussing upgrade motivation and upgrade issues. A lot of participants reported on keeping current so that you don't put yourself in a corner having an impossible upgrade in the future. Otherwise not much surprise there. The bulk of the discussion was around the impact of the release cadence. The most obvious user impact (pressure to upgrade) would be mostly covered by the work being done on fast-forward upgrades. Once that is a proven model of upgrading OpenStack, the cadence of release stops being a problem to become an asset (more choice has to where you fast-forward to). The other big user impact (support ending too early) would be mostly covered by the work being done to extend maintenance on stable branches. Again, the cadence of release is actually not the real cause of the pain felt there, and there is already work in progress to directly address the issue. That said, the release cadence definitely has cost for people working downstream from the OpenStack software release. Release marketing, and the community-generated roadmap are both examples of per-release work. We need to work on ways to make releases more business as usual and less of an exceptional event there. At this point the groups the most impacted by the release cadence are those working on packaging OpenStack releases, either as part of the open source project (OpenStackAnsible, tripleO...) or as part of a vendor product. It can be a lot of work to do the packaging/integration/test/certification work and releasing more often means that this work needs to be done more often. It is difficult for those to "skip" a release since users are generally asking for the latest features to be made available. We have also traditionally tied a number of other things to the release cadence: COA, events, elections. That said nothing forces us to really tie those one-for-one, although to keep our sanity we'd likely want to keep one a multiple of the other. Overall, the discussion on cadence concluded that ongoing work on fast-forward upgrades and longer stable branch maintenance would alleviate 80% of the release cadence pain with none of the drawbacks of releasing less often, and therefore we should focus our efforts on that for the moment. The topic of discussion then switched to discussing stable branch maintenance and LTS in more detail. The work done on tracking upper-constraints finally paid off, with stable branches now breaking less often. The stable team is therefore comfortable extending the life of Ocata for 6 more months (for a total of 18 months). This should make Ocata the first candidate for "extended maintenance" (a new name for "LTS" that does not imply anyone providing "support"). Extended maintenance, as discussed by the group, would be about letting branches open for as long as there is someone caring for them (and close them once they are broken or abandoned). This inverts the current chicken and egg resource issue on stable maintenance: we should establish the concept and once it exists hopefully interested parties will come. We discussed the need for a common policy around those branches (like "no feature backport") so that there is still some consistency. mriedem volunteered to work on a TC resolution to define what we exactly meant by that (the proposal is now being discussed at https://review.openstack.org/#/c/548916/). The afternoon concluded with the group agreeing on the need to continue the discussion on this important topic. The next stop should be a forum session at the Vancouver Summit. The release management team agreed to track progress on this between events. Thanks for reading until the end! -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
