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:
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:
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?"