Distributions

OpenStack and stable point releases

OpenStack is a large project, with lots of moving pieces. Every six months, a new release of those pieces is made, with periodic stable point releases made thereafter. But those point releases are a lot of work—possibly for little gain—so there is a discussion about whether to continue to make those releases going forward. Obviously, security and other bug fixes will still need to be made, but there may be better ways to package them for consumption by distributions and other users.

OpenStack Technical Committee chair Thierry Carrez raised the issue on the openstack-dev mailing list at the end of May. In some discussions at the Vancouver OpenStack Summit, there were questions about continuing to make the point releases. There were a number of reasons behind that discussion, which Carrez outlined:

• Some sub-projects follow their own version and release schemes, so the illusion of all of the OpenStack sub-projects having stable point releases at the same time is not really going to work.
• Making the stable point releases is a fair amount of work.
• Since the stable branches are intended to be always usable, and the point releases did not receive much additional testing, just grabbing any stable commit from those trees should be more or less the same.

He also recognized that not all of the stakeholders were present at the meeting in Vancouver, so his post was not meant as an announcement, but was, instead, a request for comment:

While many in the thread were supportive of eliminating the point releases, there were also some concerns. Ihar Hrachyshka asked about release notes, and about "changes that require operator consideration or action" in particular. Several offered up solutions to format the Git commit messages into release notes, but Carrez pointed out that those kinds of changes are generally "a failure in the stable branch process -- this branch is supposedly safe to draw updates from". For security fixes that may require operator intervention, separate "security notes" would accompany the advisories and would detail the steps needed.

The proposal from Carrez made a distinction between libraries and other components (there are quite a few of those, as shown by the 2015.1.0 "Kilo" release notes). Libraries would still receive point releases "for critical bugs and security issues", but Dave Walker wanted clarification on what is considered a library in OpenStack, since "everything in python is a library". Matt Riedemann suggested that the libraries are the dependencies for the major server components such as Nova, Keystone, Cinder, and so on.

Haïkel Guémar, who is one of the packagers of OpenStack for Fedora, CentOS, and RHEL, would like to see the point releases continue, at least in some fashion. He is concerned that a lack of point releases will lead to fragmentation, with each distribution having its own set of versions, potentially each with its own set of backported security fixes. It will be difficult for operators (and others) to determine which fixes have been made to a given version, as well. He suggested switching to a time-based system that could be automated; it would periodically tag the repository, then generate and upload tarballs. Thomas Goirand, who packages OpenStack for Debian, largely concurred with Guémar.

At that point, Carrez summarized the objections raised in the discussion, which was, as he noted, quite constructive in tone. There were four main complaints that he listed: a lack of focused attention on the stable branch that comes from having a point release, the lack of proper release notes, no common reference points for distributions and deployments to be able to compare and discuss, and the loss of a sense of what pieces work well together.

Carrez also replied to his summary, addressing each of the points in turn. Only focusing attention on the stable branch at the time of point releases is actually a disadvantage, he said; it would be better to keep the branch in good shape at all times. He thinks the release notes problem is serious, but solvable. He is concerned about losing the common reference points for deployments to describe what they are running. Finally, the "works well together" piece is largely illusory anyway, since the stable branch rules should make all of the versions on those branches work together.

In his message, Carrez did come up with some alternate plans. Plan B would be similar to the way things are currently done, though it would essentially be a time-based tag of all of the projects that were (briefly) tested together on that date. Plan C would simply allow the projects themselves to tag stable point releases in an unsynchronized fashion. Alan Pevec added a Plan D that would turn each commit into its own release number (e.g. 2015.1.234 for the 234th commit on the stable branch). Each of the plans would address one or more of the objections. Carrez neatly summarized the plans and their downsides.

No consensus emerged from the subsequent discussion. There seem to be two schools of thought, however. There wasn't a huge difference between plans A and D in some people's minds, though Carrez said he now preferred D. Others saw either A or D as a big change for users and thought C would be a better incremental step. There seem to be no real proponents of plan B, at least so far.

Conceptually, at least, eliminating the point releases is a big step. The argument, though, seems to be that they don't add much for their cost. The discussion is still ongoing, however, and no changes will be made until after the Liberty (2015.2) release due in October.

Comments (none posted)

Distribution quotes of the week

Comments (4 posted)

CentOS releases

Comments (none posted)

Debian 8.1 released

Full Story (comments: none)

FESCo, Council and Env and Stacks elections

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 613 (June 8)
• 5 things in Fedora this week (June 5)
• Ubuntu Weekly Newsletter, Issue 420 (June 7)

Comments (none posted)

Peppermint: Desktop Linux for the cloud generation (ZDNet)

Comments (none posted)