|
|
Log in / Subscribe / Register

Development

Rethinking the OpenStack development cycle

By Jonathan Corbet
February 24, 2016
The OpenStack cloud-management system project is a relative newcomer, having first been announced in mid-2010. It has grown quickly since then, and is now a core part of many commercial offerings. That growth has inevitably led to some growing pains, though. Recent discussions on a pair of proposals — one rather more official than the other — shine some light into where those pains are being felt and how the project might evolve to address them.

Stabilization cycles

Back in January, Flavio Percoco (a member of the OpenStack technical committee) posted a proposal for the addition of "stabilization cycles" to the OpenStack development process. OpenStack's process uses a six-month cycle; its many sub-projects are expected to coordinate their major releases around these cycles. The OpenStack "Design Summits" are scheduled for the beginning of each cycle. Each of these cycles brings a whole set of new features and, naturally, new bugs.

What Flavio was proposing, after a discussion in the technical committee, was that, occasionally, one of these cycles could be designated for "stabilization" changes only. The proposal included a fair amount of flexibility, in that "stabilization" could include work like refactoring and code cleanups. The period allotted for this work could be a full six-month cycle, or one of the "milestone" periods designated within a cycle. Stabilization cycles, Flavio said, could bring a number of benefits, including more bugs fixed, a reduction in the review backlog, and the ability to focus on larger features that require more than one cycle to implement.

Much of the discussion focused on the potential costs of stabilization cycles. One cost that a number of participants found surprising was that, it seems, a number of companies give bonuses to developers when they get features merged into the OpenStack mainline; a stabilization cycle would thus cost those developers money. There seems to be fairly widespread agreement that this kind of compensation model runs counter to the interests of an open-source project in general, but that doesn't change the fact that this model appears to be in use at some companies.

The bigger problem, though, is that, over the years, it has been shown that stabilization cycles tend not to work well in large, fast-moving projects. The kernel used to work in that model; a look at the 2.4 cycle gives a good example of how these things can go wrong. The refusal to accept features into the mainline does not stop the development of those features or magically create more resources for the fixing of bugs. Companies continue to develop the features that they want; they will then either try to sneak them in as "bug fixes" or simply ship them without bothering to merge them upstream first. The results tend to be less stability and more fragmentation in deployed versions of the code.

Based on this experience, James Bottomley recommended against the idea of stabilization cycles, suggesting instead that the OpenStack cycle should be reworked to look more like how the kernel does things:

I still think what OpenStack actually needs is simply a longer stabilisation time. Right now, in the 6 month cycle, there are about five months of development beginning with the design summit and one month of -rc stabilisation. In today's model, to extend stabilisation you have to steal time from feature development, which again causes a lot of argument. To fix this, I'd turn that around and make it one month of feature merging followed by five months of -rc stabilisation.

To do this, he said, OpenStack would need to establish something like the linux-next tree for early integration and testing of new code. He also suggested that the design summit should be moved toward the middle of the development cycle to facilitate discussion of work that is aimed at the next merge window.

The discussion on this proposal eventually wound down without any firm conclusions beyond a sense that there was little interest in the establishment of project-wide stabilization cycles. Thierry Carrez (OpenStack's release manager and chair of the technical committee) suggested that the most important thing would be to communicate to the sub-projects that any of them could impose their own stabilization cycles if that seemed appropriate to them.

Reclaiming the design summit

James's suggestions for a reworked development cycle seem unlikely to be taken up by the project anytime soon, but one specific idea — changing the timing of the design summit — came back in a modified form in late February. The "design summit" event, which started as a small group of developers getting work done, has, over time, been overwhelmed by the OpenStack Summit, a rather larger, co-located event with a disturbingly high necktie-to-T-shirt ratio. That has led to developers feeling that the original purpose of the event has been lost; as Jay Pipes (another technical committee member) put it:

With the OpenStack Summit growing more and more marketing- and sales-focused, the contributors attending the design summit are often unfocused. The precious little time that developers have to actually work on the next release planning is often interrupted or cut short by the large numbers of "suits" and salespeople at the conference event, many of which are peddling a product or pushing a corporate agenda.

Jay suggested that the design summit should be split off from the main conference so that the developers could gain a respite from the suits at a more focused, less glitzy, and less expensive gathering.

It turns out that Thierry had been working on just this type of idea; he posted his proposal on February 22. The plan is to split the OpenStack Summit into two separate events. The first would be a technical event "held in a simpler, scaled-back setting" aimed at getting work done. This gathering would happen in relatively inexpensive locations, in the hope that companies would be more willing to send more of their developers.

The second event, instead, would be "the main downstream business conference, with high-end keynotes, marketplace and breakout sessions". It would, presumably, remain in relatively fancy, suit-friendly locations. In addition to serving the needs of the business community, it would be intended to serve as a location where feedback on releases could be gathered, along with requests and requirements for future releases.

The new, currently unnamed developer conference would be held toward the end of the development cycle, a couple of weeks before the release happens. That would allow the discussion of work that is planned for the next cycle, and on any last-minute release problems as well. The business event, instead, would move to the middle of the development cycle. At that point, the previous release will have been around for long enough to find its way into products and for companies to have learned about its good and bad points. The next cycle, meanwhile, is far enough away that feedback from the conference can still be incorporated. The new scheme would be phased in next year, with the first "contributors event" happening in February 2017. Thierry provided a timeline diagram [PDF] to illustrate how it would work.

Response to the proposal has been mostly positive, though Michael Krotscheck worried that it heralded the beginning of the end for the design summit. Sales and marketing is where the money is, he said, and a conference that excluded them would not do well in the corporate priority-setting process. Another potential concern, raised in the previous discussion, is that the ability to meet the developers is one of the selling points of the main conference. If the developers are no longer there, that conference, too, will suffer.

In the end, though, a development conference needs to be a relatively small and focused affair if it is to be a place where a lot of work gets done. The proposed event split might just make that possible, though the size of the project now ensures that a gathering of its developers can only be so small. In general, the problems faced by OpenStack are the kind of problems that many other projects can only hope for. Success tends to force changes; we have probably only begun to see the ways in which OpenStack will need to change to remain successful in the coming years.

Comments (none posted)

Brief items

Quotes of the week

But just because there is a skill-based fence around your project, does not mean there's no gate in that fence. Let's back up to the hypothetical snob's argument: "We don't want just anyone throwing patches into the repository. They need to know what they are doing." This is very true. But the rest of that statement needs to be: "…and we need to show them how to participate."
— Brian Proffitt

For some reason the httpd status pages (e.g. 404) use the Comic Sans typeface. This patch removes comic sans and sets the typeface to the default sans-serif typeface of the client.

This lowers the number of people contacting website maintainers with typeface complaints bordering on harassment.

— Peter Krantz

Comments (none posted)

Ardour 4.7 released

Version 4.7 of the Ardour digital-audio workstation has been released. The update includes two key new features: a dialog that displays detailed spectral and waveform analysis for exported files, and substantially improved support for Mackie Control brand hardware control consoles. Many other improvements are listed in the announcement, including preliminary support for importing work from ProTools 10 and 11.

Comments (none posted)

GNU C Library 2.23 released

Version 2.23 of the GNU C Library (glibc) has been released. The headline feature this time around seems to be Unicode 8.0.0 support; there are a number of API changes, performance improvements and security fixes as well.

Full Story (comments: 6)

Libinput 1.2 released

Version 1.2.0 of the libinput library is now available. New features include support for three-finger "pinch" gestures and the ability to independently toggle support for tap-and-drag and tapping in general. Also noteworthy is that the motion hysteresis feature is now disabled by default. "This provides smoother motion especially on small to tiny motions, making single-pixel elements much easier to target. On some devices, especially older touchpads the hysteresis may be required. We've enabled a bunch of those already, if you notice the pointer wobbling when hold the finger still, please file a bug so we can fix this."

Comments (none posted)

Newsletters and articles

Development newsletters from the past week

Comments (none posted)

Upcoming features in GCC 6

The Red Hat developer blog looks at what's coming in version 6 of the GNU Compiler Collection. "The x86/x86_64 is a segmented memory architecture, yet GCC has largely ignored this aspect of the Intel architecture and relied on implicit segment registers. Low level code such as the Linux kernel & glibc often have to be aware of the segmented architecture and have traditionally resorted to asm statements to use explicit segment registers for memory accesses. Starting with GCC 6, variables may be declared as being relative to a particular segment. Explicit segment registers will then be used to access those variables in memory." The GCC 6 release can be expected sometime around April.

Comments (37 posted)

Qt Roadmap for 2016

At the Qt blog, Tuukka Turunen sets out the project's roadmap for the coming year. Three releases are currently scheduled: Qt 5.6 in March, Qt 5.7 in May, and Qt 5.8 in October. Of note, the 5.6 release will be designated a Long Term Support (LTS) release: "As part of our LTS promise, we guarantee that Qt 5.6 will be supported for three years via standard support, after which additional extended support can be purchased. During this time period, even though following Qt releases (Qt 5.7, Qt 5.8 and so on) are available, Qt 5.6 will receive patch releases providing bug fixes and security updates throughout the three-year period after the release." New features on the roadmap include high-DPI support, C++11 support in Qt modules, and dropping LGPLv2.1 as a licensing option (in favor of LGPLv3).

Comments (none posted)

Page editor: Nathan Willis
Next page: Announcements>>


Copyright © 2016, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds