It's Not Time for OSS Release Cycle Synchronization

Bakkies Botha writes "Ars Technica weighs in with some detailed analysis on the controversial issue of open source release cycle synchronization. Ars explains how time-based release cycles work and takes a close look at how the release management strategy suggested by Ubuntu founder Mark Shuttleworth would impact open source software projects. Ars concludes that Shuttleworth's proposal isn't currently viable and argues that the BFDL is overstating the potential to simplify development with better version control tools. Ars also examines a counter-proposal offered by KDE developer Aaron Seigo and explains how it enables users to get the same benefits of synchronization without disrupting upstream development."

if I was in charge of a FOSS project

[FudRucker]

I would release when it was ready, not when some stupid release cycle rolled around, that is what everyone does not need is some schedule to pressure developers to release before a product is ready...

Translation of Seigo's suggestion

[InlawBiker]

"Why don't you quite whining and help us develop and release the software you're re-packaging and trying to make money from."

This was a good article. The Internet was actually useful today.

Imho

[Joseph1337]

The benefits aren`t worth it. Look at Vista and KDE4, they were released too soon and look what happened - you got half of the promised features and half of the stability

Re:if I was in charge of a FOSS project

[maxume]

The idea of the schedule is not to encourage a premature release, but to encourage a sufficiently attainable definition of "ready" such that a release eventually happens.

Re:if I was in charge of a FOSS project

[InlawBiker]

There really isn't a perfect way to release Linux distributions. With timed releases components are prioritized quickly, but some stuff gets left out. With feature-based releases you have to wait until some number of components are ready so the release date is a mystery.

I think it's great the way it is: each distro has their own method, you can pick the one that's right for you. It's the ultimate in technical Darwinism.

Re:if I was in charge of a FOSS project

[trolltalk.com]

The idea of the schedule is not to encourage a premature release, but to encourage a sufficiently attainable definition of "ready" such that a release eventually happens.

Best definition: "It'll be ready when it's ready."

This is the same truth, whether you're talking about open or closed-source, free/libre or proprietary software.

Trying to alter this basic truth results in death marches, bad, bug-ridden software, disaffected developers, dissatisfied users, and "we'll fix that in the next release" bullsh*t.

If it ain't broke...

[file_reaper]

...then why fix it? No seriously, is there something really wrong with the way distro's are released today? Or is this just for Ubuntu to add another check to the "we invented that here" list. Plus there are the excellent points made in the above post "A lot of buzz" by bsDaemon.

Re:if I was in charge of a FOSS project

[maxume]

Sure, but you can at least prioritize certain features, which is then essentially a schedule, and you might as well release features once they are ready (because, as you say, they are ready).

Re:if I was in charge of a FOSS project

[RiotingPacifist]

OFC not specifying a schedule leads to e17, hurd, etc

Re:A lot of buzz

[garett_spencley]

"seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories?"

One that targets non-developer desktop users ? Or even servers ?

As a sysadmin one of the many tasks I do to vanilla installs is to either uninstall the dev tools or restrict them to a particular group. Many exploits automatically download source for their rootkits or trojans etc. and compile it on the machine. Not having dev tools available to the user that the web server is running under, for example, makes these types of attacks more difficult and helps limit what an attacker can do if he does gain access (imagine a scenario where the attacker has no shell but can tell the web server to execute commands ... a simple 'wget' and 'make' later and he has himself a back door that gives him shell access as the web server user).

In other words, if you have no pressing need for dev tools then it's wiser not to have them installed. If you're a developer then you can easily add them via the repositories.

Re:A lot of buzz

[Anonymous Coward]

Trying to sync up Red Hat or SuSE who have more or less gotten out of the consumer market and are targeting professional users - developers, engineers, etc - in the workplace environment with some candy-for-kids distro is frankly a little weird.

If some distributions use a common set of libraries and applications then why shouldn't they be interested in better synchronization with upstream development? It doesn't matter who the distribution is targeted at.

The goal seems to be to increase homogeny across distributions - however, homogeny between ubuntu and rhel? quite frankly, why?

Take a C compiler as an example. Are you suggesting that Ubuntu and Red Hat would want different versions of the C compiler on the basis of their users? I don't see the advantage of heterogeneity here.

The systems are targeted at different sets of people with different requirements and philosophies. Holding off on releasing Red Hat until Ubuntu is ready, which requires KDE and GNOME to sync up (more or less) sounds a little ridiculous and over-the-top.

Good thing no one suggested that then. If Ubuntu misses the release date, why would Red Hat wait? The whole point of synchronizing release dates is so that there is a common timeline. Since Ubuntu is not upstream from Red Hat, there would be no logical reason for Red Hat to delay (unless both delays are caused by a serious problem upstream).

Sync would please ISVs

[HighOrbit]

I think syncing the major distro's would be a boon to Linux overall. It would make support easier for third party vendors and ISVs, which might induce them to release more major Linux applications. For instance, Oracle or Adobe whould know that a particular version of their product would only have to support a certain kernel (altough each distro has patches) and a certain version of Gnome and/or KDE as opposed to ten different point-releases of kernel,KDE, and Gnome. The would know which versions of the Gnu utililities they can expect to support.

Anything that makes it easier to for major software vendors to release and support software makes Linux stronger.

Way To Go Aaron

[mpapet]

Shuttleworth's idea is designed to further Ubuntu at the expense of the projects packaged therein. Specifically, he's trying to shift quite a bit of the release work onto the projects he packages.

Aaron's post is a must-read for anyone vaguely interested in the topic. In particular,
It is not overly dramatic to say that if we make Free software development overly sterile via choice of process, there will be a commensurate diminishment in participation and momentum. I interpret that as Aaron recognizing the corrosive effect on the entire dev community by adopting Shuttleworth's scheme.

Better still, Aaron offers constructive alternatives. It's really nice to read and should be a template for most blogging.

Someone please explain why Shuttleworth's idea hasn't been swatted down the day he posted it.

Today's lesson: Learn to disagree without personal attacks and offer viable alternatives.

Re:Not only a development issue

[RiotingPacifist]

meet debian lenny (testing)

Re:A lot of buzz

[Kjella]

seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories?

Uhh... a system that you USE? My car came with an instruction manual, not a mechanic's manual and tools. Compiling code others have compiled before is a total waste of time (sorry gentoo), I haven't got any clue why my home server, my htpc, my desktop or my laptop should possibly need a compiler unless I happen to be a developer. Particularly not the boxes I set up for my parents which they're happily using but would have as much use for a compiler as an ERP system.

The goal seems to be to increase homogeny across distributions - however, homogeny between ubuntu and rhel? quite frankly, why?

- Stronger competition on distro features, not just "free" features they got from upstream
- Less support costs, they probably share a lot of packages in the backend
- Better consistency of software quality (all have the same release window to plan for)

Holding off on releasing Red Hat until Ubuntu is ready, which requires KDE and GNOME to sync up (more or less) sounds a little ridiculous and over-the-top.

It's a bit of circular reasoning going on in the article, it for example pulls out Ubuntu 8.04s pulseaudio configuration issues - try reversing the question, if pulseaudio knew that was the release window would they have worked much harder to hit it? Or just really miss it and get it really well done for the next release? I'm pretty sure they aren't doing it just for their own amusement and would like it to be included in distros as well.

Sure, things don't always go after plan and some projects would miss deadline windows and such. But compare that to the alternative, "when it's ready" basicly means they'll release all over the place and a distro would be an odd mix of old and new. If all projects knew this was the window I'm pretty sure most would manage to hit it. I think the "anti-synching" argument is rather poor because it's better to try to plan a scope than not making any plans at all. Seriously, the same applies inside a project and I assume you'd like all parts to have "releasable" code at the same time? Not easy if noone knows when it needs to be so.

I do think it's a bad idea, but not for any of the reasons you mention. I think this big break-and-release cycle will just lead to poorly tested software and a huge number of bugs after the synched release, since almost everyone will be waiting for that. I can deal with some new software on my distro, others can deal with some new software on their distros - but I think dealing with all new software would be an exercise in frustration, even with so many testing it.

Re:if I was in charge of a FOSS project

[Uncle Focker]

And the amount of usability versus development time far eclipses Hurd by many magnitudes. KDE4 was especially a clusterfuck, but in comparison to the usability of Hurd after 24 years, they're in totally different ballparks.

Re:A lot of buzz

[Uncle Focker]

If all I wanted to do was basic, every day tasks, Win2k or XP would be more than sufficient. I wouldn't need anything else. Application availability would not be an issue.

But what if one wants a free OS to do all those things? Why should they have to have Windows? Why do you get so bothered over someone using your 1337 OS to do only simple tasks?

It wasn't supposed to be "for grandma." Stallman and the FSF, with their evangelistic, holy-war approach to software may have confused the issue. "free software for everyone! information wants to be free!"

I don't really care who you've deemed it "for". My grandma uses Ubuntu just fine to do what she needs and saved herself a few hundred dollars over having to buy Windows.

If the reason you want grandma to run unix is because you're sick of having to clean spyware off of her system, frankly it very well may be overkill. It's like using an elephant gun to hunt a squirrel.

No, I had it installed on the Dell machine she bought because it saved her money and it can do everything she needs.

However, it seems to me that if people want to come to a *nix system, they should take the time to learn how and why things are the way they are. I can see no benefit from trying to make the system more like windows, because it will just cause confusion and frustration.

Why should they have to? I've never understood this attitude where one has to become a power user or one is banned from using .

Re:Way To Go Aaron

[lazy_nihilist]

Shuttleworth has a done a great job with Ubuntu. I think his latest idea about synchronizing releases is a good one myself. But as always, I might not be right. The best thing this has done is we have come up with a discussion on how to make release proccesses better for the improvement of the whole Free Software Community.

As you said, we should learn to disagree without personal attacks and offer viable alternatives. Now that Aaron Seigo has provided an alternative view, we can discuss that as well and try to improve the overall process. If we can do that properly I see this only benifitting the FOSS Community.

Re:if I was in charge of a FOSS project

[firewrought]

It'll be ready when it's ready.... Trying to alter this basic truth results in death marches, bad, bug-ridden software, disaffected developers, dissatisfied users, and "we'll fix that in the next release" bullsh*t.

If you're landscaping your yard, you can take as long as you want and spend as much money as you want. If someone else is landscaping your yard, you become much more interested in how long it will take and how much it will cost: giving them your credit card and letting them keep a running tab is not an option.

Similarly, if you're doing leisure or volunteering programming, you can tell the world "It'll be ready when it's ready." Much of Open Source falls under this umbrella. Most of the business world does not. The professional programmer enforces up-front and on-going trade-offs between features, quality, and schedule risk. When they can't or won't (sometimes due to politics), then you get the bad stuff you mention. One way or another though, schedules are a business necessity.

I suspect that, even for volunteer programming, schedules can be useful. Deadlines force you to think about where you want to be by the time the deadline rolls around. They give you a goal. They force you to cut unneeded features and focus on the core strengths/concepts of your product.

Likewise, the lack of a schedule--especially the "It'll be ready when it's ready." attitude--can be severely damaging. If you haven't hammered out a detailed plan of what you want to accomplish and you've left it all open-ended, you can get lost spending lots of time choosing a programming language or gold-plating a feature that nobody will use. Is this why there are so many defunct OSS projects on SourceForge? I bet it's part of the reason... most software their has no business driver to give them momentum.

Re:A lot of buzz

[Uncle Focker]

Its not about being "banned from using" -- its about the right tool for the job.

And a free OS that does everything she needs is the right tool for the job.

Widnows isn't /terrible/, except maybe from an engineering standpoint.

I never made any such pronouncements on the quality of Windows.

Vista may be terrible, but that's not the point. Win2k pro and XP pro are pretty unobtrusive.

And they also cost more money for some people than it's worth when a free OS can do everything they need.

Why is it that "the right tool for the job" only seems to apply between linux distros around here. if I were saying 'use a mac,' then I might get modded up for it, too though.

Why is it that you care what some random person uses to do what they want?

Look at it this way -- if I need to apply baseboard molding to the wall in my house, I /could/ use a nail gun, but a hammer would do just fine.

Yeah, and if all a person wants to do is browse the web and read email, why should they spend a few hundred dollars for an OS that they don't need?

I would whole-heartedly endorse an operating system designed from scratch to serve the needs of plain ol' users. However, trying to take a model of operation and then bend it and break it into something it wasn't meant to be under the guise of "but it /can/ be all things to all people" seems a tad misguided to me, perhaps even lazy.

What is being bent and broken in Linux to do basic tasks like read email and browse webpages? You've still yet to explain exactly why anyone should not use Linux other than your snobby attitude that they either have to be a power user or they need to GTFO.

Of course, maybe its just that the implementations so far just seem to fall short.

Fall short of what? With Ubuntu most regular users can do all the basic tasks they need. Not everyone uses BSD or Linux to do kernel hacking and code development nor should that be a requirement for usage. Seriously, get over yourself. You're not cool and 1337 cause you use a *nix OS and you can stop trying to force people away because they don't share your snobbiness.

Re:Way To Go Aaron

[Eponymous Bastard]

Did you even read the articles?

Shuttleworth is saying that if the distros synchronized, upstream developers would have better information about release cycles and could chose whether to target a particular release with their new features or not (essentially, when to branch for release and focus on stabilization). If it's not ready, then it's not ready and just shoot for 6 months later.

This guy Aaron makes a good point in that this shifts work upstream, but I don't agree that this is disruptive. Aaron's great idea? Have the distributors basically go into each and every project and make and manage the release branches themselves! Imagine someone else coming into your project and going "We're branching here because I said so". Gee, not very good with people is he?

If the distros synchronize, upstream can just ignore it if they feel like. There isn't really much of a downside. If you do chose to synchronize you can still have features released when they are ready, but deployments (releases/tarballs) happening on schedule. It's just a matter of which branches you merge.

On Ars' theory that big changes are prevented by a branch and merge, timed release approach, GCC has used a 3-stage (major change, improvement, stabilization) release cycle since GCC 3.1 in 2001. Rather large changes have been done since then until the 4.4 branch in development. Granted, Mark Mitchel has done a superb job at release management (i.e. cat herding) and recently had 3 more people join in in this job.

Even Linus does this fairly often (change too big, goes in next version so we can push this one out the door)

At best, distros could help with consulting and advising on this job, but the release planning and management must come from within each community. His point about shifting work is good, and release management for big, flaship projects could be provided by people from each company (as I'm sure redhat et al have people working on each project anyway), but big projects probably have something like it established anyway.

I'm still not seeing the downside to synchronized but ignorable schedules downstream.

Re:Counter-proposal?

[xenocide2]

That cuts both ways. If you change the package, you're not reflecting some crazy will of the developer or making them look bad etc. If you don't upgrade it often enough, the developer (and some users) get angry that you're still shipping old code of theirs. If you just ship upstream releases 0day, shit breaks. I just witnessed a package in universe complain that Hardy didn't ship their latest version, even though it was basically a surprise release well after FeatureFreeze and a week or so before the FinalFreeze. Nevermind that their first cut at the release totally broke the program and they had to release a version bump a day later. Many upstreams are terrible at release management, and distributions are valuable because they do that work.

Bottom line is if you want the distro to help you, understand the distro first.