Back in April 2008, Canonical’s Mark Shuttleworth pitched the idea of major open source projects synchronising their release cycles on a 6 month period. Projects like gcc, the Linux kernel, GNOME, KDE, as well as the distributions, would work out an acceptable release schedule. It would allow for easier collaboration between the various projects, and hardware vendors would be better able to support Linux since all major distributions would ship with the same kernel version.While the idea sounds appealing, there are of course a number if issues that would present themselves, as Aaron Seigo, of KDE, pointed out in a few blog posts. An important complaint from Seigo revolves around the idea that a 6 month release cycle would have the downside of more features being pushed to the next release, especially in big projects. “For some apps this is a complete non-issue, but for more complex bodies of code that are in high development states a 3 month feature window is just too tight to fit in more than a few things,” Seigo explains, “The first month of a release cycle is usually not spent on new features in my experience, and the last couple of months in a 6 month cycle are spent stabilizing.”
A possible solution would be to make optimal use of branches, where development on specific features happens outside of the main tree; this way development on features that are not fitting for a 6 month release cycle can continue during freeze. Seigo has his reservations about this, as he explains: “This is where I get really uncomfortable, though: to solve the issue with an inappropriately sized cycle, I end up moving the development away from the KDE infrastructure which is totally counter productive from the perspective of shared development.”
Shuttleworth decided to reply, addressing various problem points put forward by Seigo. On the issue of postponing features because they don’t make it in time for the release cycle, Shuttleworth states:
It’s unfortunate that features don’t always happen on the schedule we hope they might. But it’s worth thinking a little bit about the importance of a specific feature versus the whole release. When a release happens on time, it builds confidence in the project, and injects a round of fresh testing, publicity, enthusiasm and of course bug reports. Code that is new gets a real kicking, and improves as a result.
He goes on to explain that Free software projects are not like proprietary projects in that while the latter needs to push out features despite them being ready or not, the former has the advantage of being able to postpone features. “We can choose to slip a particular feature in order to get a new round of testing and feedback on all the code which did make it.”
Shuttleworth also explains that synchronising releases schedules should not mean that everyone releases their tarballs on the exact same day. Just as Aaron proposed, you would need a cascading release cycle, where certain projects release first (“Linux, GCC, Python, Java, Apache, Tomcat, etc.”), followed by a second set (“applications, the desktop environments and other utilities”), and a third set (“the distributions – Ubuntu, Fedora, Gentoo, possibly Debian, OpenSolaris”).
Yesterday, the back-and-forth continued as Seigo addressed Shuttleworth’s latest blog post. In Shuttleworth’s post, there’s a great deal about the benefits of branched development – merging features back in “when they are ready”. Seigo counters:
Mark suggests doing development in branches and merging them in “when they are ready”. This obviously favors the release process which is a point in time event that requires a fraction of the resources involved in the actual development process. Given that the creative process is ongoing and consumes the bulk of resources, the release process should flow from the development process not the other way around.
Seigo then takes it all quite a few steps further, with an idea that he acknowledges is rather radical. “Why doesn’t downstream take on producing releases? Why not cease waiting for tarballs to be delivered to your doorstep and start working on a release engineering service!” Seigo envisions “the system integration community” (which would be the distributions, mostly) taking care of the releases of the various projects involved. “Instead of hoping that upstream does what they want, why don’t they rally a bunch of cohorts from Novell, Red Hat, Debian, Mandriva, the MacOS and Windows communities, Canonical and whomever else wishes to engage and start offering a real, serious release process for upstream development to filter into?”
I know this would be a non-trivial investment, but if Mark is truly serious about what he suggests this would be a very compelling way to put his currency where his mouth is, so to speak. Stop trying to convince the world and just start doing it.