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?”
Seigo finishes:
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.
There are tons of people from Red Hat and Novell working on the kernel, Gnome, KDE, the compiler tool chain, and much else. Ubuntu/Canonical is getting big enough that they could manage to do more.
sure
Edited 2008-05-19 20:25 UTC
Getting big in terms of users or consumers is very different from getting big in terms of upstream contributions. Unless you have a lot of upstream contributions, you can’t really drive it strategically in the direction you would prefer. Red Hat only has the ability to support critical infrastructure for customers because it contributes heavily in that area
http://fedoraproject.org/wiki/RedHatContributions
The more critical it is, the more contributors you need and that’s why you see Red Hat as the largest contributor the Linux kernel and employing maintainers of glibc, gcc, many of the GNOME components etc. This isn’t charity. It just makes business sense to do that if you are making your money selling services around Free and open source software. Since you can’t lock in your customers, this is the real way to provide value (unless you want to mix and match with proprietary software in between which is rather tricky to do if you are building a community).
If Canonical wants to drive sync release schedules, it can’t merely hope to float the idea and get everyone to agree. Contributions in the ground level is what earns the trust of the community to actually listen and help. Pick and choose what is considered as critical for your distribution and employ people or sponsor people already working on those areas.
I agree completely. I think Ubuntu is getting a bit too big for its breeches and thinks that just because of the buzz it’s been getting lately, it can start pushing around the rest of the (established) community. The reality is, most of the work that Ubuntu benefits does not come from Ubuntu. It’s not even really its own distribution, with Debian providing the base and a lot of QA and development work.
I think Shuttleworth is correct in believing that there should be more synchronization between the various projects and not just on a single distro level. He is wrong, however, to think that all the distros should just bend over because Ubuntu says so. If Shuttleworth and Canonical are serious about this, they could start by having Ubuntu sync with a few more core projects as well as putting more work into other projects that they find important. Since they have been serious about X stability, they should hire people to work full time on X development (God knows, X needs more serious developers) and then start talking about coordinating release schedules.
Just my $0.02.
Please read the posts. If you agree that there should be more synchronization between the various projects you agree with what Mark has suggested. Because that is pretty much all he has proposed. If anything, it is Aaron who is suggesting that all the distros bend over backwards to help KDE do its releases.
Edited 2008-05-20 03:29 UTC
Mark is basically trying to get projects to synchronise with Ubuntu’s six month release cycle – for Ubuntu’s downstream benefit.
If Mark wants some kind of coordinated release mechanism then he’s going to have to put something into it. Aaron suggested one way he might be able to do that, as it is not up to upstream projects to compromise their feature list to stick to Ubuntu’s six month release cycle.
It’s Mark who’s asking for this.
Ubuntu’s timetable is practically the same as Gnome’s timetable, its not something they pulled our of their ass. So what he is suggesting is that All projects adhere to a set timetable and release cycle that a major OS project already uses and that many projects revolving around it use as well. Its a sound idea, but because it was suggested by the Ubuntu community its not valid. As a community we contribute a lot to the linux landscape, even if Canonical as a company may not. The huge user base of ubuntu has spawned many oss projects that are built and maintained on Ubuntu, but because some of these projects aren’t huge upstream projects they get overlooked and Ubuntu doesn’t contribute?
Aaron has no intention of making the KDE project use a steady release cycle, he has stated as much before, when Mark suggested the same thing for KDE a while back. I say regular less feature centric releases would be a benefit to KDE, but Aaron thinks otherwise and is willing to be an ass to support his opinion.
Ubuntu may not have a lot of upstream developers, but like I’ve stated many times on this site. Ubuntu’s popularity doesn’t translate to money, they are popular, but unlike RedHat or Novell, they have very little resources that are not coming out of the pocket of one man. So its nice for Aaron to say that Ubuntu should contribute more upstream, but the reality is that Ubuntu doesn’t have the resources to do such a thing.
What makes Ubuntu great, is the fact that in just the few short years that they have been making releases, they have changed the landscape of consumer oriented(desktop) Linux. Anyone who denies that is lying to themselves. They must have contributed something to make such a huge impact in so little time. It’s not about what they contribute but how. Many projects that started on other distros were fostered and nurtured by the huge Ubuntu community. Ubuntu contributes by increasing adoption rate and awareness of Linux, that should be more than enough, imo.
This is not entirely true. MArk isn’t suggesting that everyone adapts to Ubuntu’s/GNOME’s schedule. In fact, he clearly stated Ubuntu is willing to change its release cycle if needed.
Change the release cycle to match conflicting upstream release schedules and distribution release schedules doesn’t really work. Enterprise releases are only put out every 2 years or so. I doubt he isn’t willing to only release to match that. The GNOME release schedule originated from the Red Hat Linux release schedule
http://fedoraproject.org/wiki/Releases/TimeBased
Fedora, Ubuntu, OpenSUSE, Mandrive release schedules already match to a good extend in a organic way. Upstream projects already do accomodate these releases.
That’s not where the problems with his idea lie.
Same difference. Whether it’s Ubuntu’s or Gnome’s timetable it doesn’t solve the problems.
All projects have their own goals for each release, and as Aaron pointed out, for projects who have a timetable of major structural changes and want to get more far-reaching features implemented, which happens from time to time, a six month release cycle is an total ass.
Aaron is spot on to be sceptical about strict time based releases. Quite often, and Gnome has suffered terribly from this, major features and changes that should be made are continuously put on the backburner for future releases because the next release just comes up far too fast. Just because you can make a release, it doesn’t mean that there’s anything actually in it. From that we get the suggestion of better branching so that features can be backported more easily. It’s all in the articles.
KDE does have time-based releases actually, but they’re not willing to be strict about them because open source development just isn’t like that.
This seems like a good idea but I’m not sure how it would work.
Are we talking about dependencies here? Aren’t people already working as fast as they can to use new features of libraries their stuff depends on?
Lets say there is a program that you use written in PyQt. The authors want to use a new feature of Qt that is going to come out. As a user of the program you have to wait first for the Qt release, then the PyQt release, then the author of that program to use the new feature.
How could this happen in any other order and still get proper testing?
It’s more of a business thing. If all major distributions ends up using the same version of gcc, the linux kernel, etc in their releases (which in turn are released in the same time-frame) hardware vendors for example will have an easier time supporting those releases with drivers.
It’s not really about bringing new features of underlying libraries to the users in a different way or a faster way, it’s more of how to make Linux more attractive to the enterprises.
It’s more business as usual than anything else :
Dag Wieers : http://dag.wieers.com/blog/ubuntus-need-to-catch-a-wave
Too many capital letters … has he learned how to use the shift key finally?
Rehdon
(Note for the humour impaired: just a joke!)
I’ve been reading the articles here and on Slashdot lately and there seems to be alot with the opinion that Ubuntu is a good choice cause its the best desktop distro. But I need to know what have they done to make it the best? Its like nobody is calling ubuntu out for thier claims. I know about the sudu thing. nice idea but other than that what makes them a great desktop? I mean Novell and RedHat are the ones submitting all the usability patches upstream. Re-designed gnome with all those 2.4-2.6 usability improvments.
Why is ubuntu the undisputed king?
The King is in the altogether,
But altogether the altogether,
He’s altogether as naked as the day that he was born.
Edited 2008-05-20 11:25 UTC
They are king because of marketing, nothing else. And the marketing is because they are incredibly open, and give free cd’s to everyone. They don’t contribute as much as the big ones like Mandriva, Suse and Red Hat, yet everyone perceives them as huge contributors because many ppl working on Gnome use Ubuntu… But they’re not paid.
edit: with ‘not paid’ I mean not paid to do the work on Gnome etc, of course.
Edited 2008-05-20 15:45 UTC
I think first distributor or the Linux Foundation or someone need to identify critical FOSS packages and employ someone to maintain them full time.
Having no committed maintainer for Openssl is pathetic. Although this time the fault was Debians it still cannot be excused that there is not better support such a crucial package. A full time committed maintainer might have helped.
It is always good to have someone whose job it is to care for software.
There are probably other packages.
There’s a Spanish idiom that goes “ir a por lana y salir trasquilado”, that is, “going for wool and ending up shorn”. I think this would apply to Mark Shuttleworth if Aaron Seigo’s idea catches on