The content below is taken from the original (OpenStack Developer Mailing List Digest November 7-13), to continue reading please visit the site. Remember to respect the Author & Copyright.

New Management Tools and Processes for stable/liberty and Mitaka

• For release management, we used a combination of launchpad milestone pages and our wiki to track changes in releases.
• We used to pull releases notes for stable point releases at the time of releases.
• Release managers would work with PTLs and release liaisons at each milestone to update launchpad to reflect the work completed.
• All this requires a lot of work of the stable maintenance and release teams.
• To address this work with the ever-growing set of project, the release team is introducing Reno for continuously building release notes as files in-tree.
  • The idea is small YAML files, usually one per note or patch to avoid merge conflicts on back ports, which are then compiled to a readable document for readers.
  • ReStructuredText and Sphinx are supported for converting note files to HTML for publication.
  • Documentation for using Reno is available [1].
• Release liaisons should create and merge a few patches for each project between now and Mitaka-1 milestone:
  • To the master branch, instructions for publishing the notes. An example of Glance [2].
  • Instructions for publishing in stable/liberty of the project. An example with Glance [3].
  • Relevant jobs in project-config. An example with Glance [4].
  • Reno was not ready before the summit, so the wiki was used for release notes for the initial Liberty releases. Liaisons should covert those notes to Reno YAML files in stable/liberty branch.
• Use the topic ‘add-reno’ for all patches to track adoption.
• Once liaisons have done this work, launchpad can stop being used for tracking completed work.
• Launchpad will still be used for tracking bug reports, for now.

Keeping Juno “alive” For Longer

• Tony Breeds is seeking feedback on the idea of keeping Juno around a little longer.
• According to the current user survey [5], Icehouse still has the biggest install base in production clouds. Juno is second, which means if we end of life (EOL) Juno this month, ~75% of production clouds will be running a EOL’d release.
• The problems with doing this however:
  • CI capacity of running the necessary jobs of making sure stable branches still work.
  • Lack of resources of people who care to make sure the stable branch continues to work.
  • Juno is still tied with Python 2.6.
  • Security support is still needed.
  • Tempest is branchless, so it’s running stable compatible jobs.
• This is acknowledged as a common request. The common answer being “push more resources in fixing existing stable branches and we might consider it”.
• Matt Riedmann who works in the trenches of stable branches confirms stable/juno is already a goner due to requirements capping issues. You fix one issue to unwedge a project and with global-requirement syncs, we end breaking 2 other projects. The cycle never ends.
• This same problem does not exist in stable/kilo, because we’ve done a better job of isolating versions in global-requirements with upper-constants.
• Sean Dague wonders what are the reasons that keep people from doing upgrades to begin with. Tony is unable to give reasons since some are internal to his companies offering.

Oslo Libraries Dropping Python 2.6 compatibility

• Davanum notes a patch to drop py26 oslo jobs [6].
• Jeremy Stanley notes that the infrastructure team plans to remove CentOS 6.X job workers which includes all python 2.6 jobs when stable/juno reaches EOL.

Making Stable Maintenance its own OpenStack Project Team

• Thierry writes that when the Release Cycle Management team was created, it just happen to contain release management, stable branch management, and vulnerability management.
  • Security Team was created and spun out of the release team today.
• Proposal: spin out the stable branch maintenance as well.
  • Most of the stable team work used to be stable point release management, but as of stable/liberty this is now done by the release management team and triggered by the project-specific stable maintenance teams, so there is no more overlap in tooling used there.
  • Stable team is now focused on stable branch policies [7], not patches.
  • Doug Hellmann leads the release team and does not have the history Thierry had with stable branch policy.
  • Empowering the team to make its own decisions, visibility, recognition in hopes to encourage more resources being dedicated to it.
    • Defining and enforcing stable branch policy.
    • If team expands, it could own stable branch health/gate fixing. The team could then make decisions on support timeframes.
  • Matthew Treinis disagrees that the team separation solves the problem of getting more people to work on gate issues. Thierry has evidence though that making a its own project will result in additional resources. The other option is to kill stable branches, but as we’ve seen from the Keeping Juno Alive thread, there’s still interest in having them.