KDE and a periodic release cycle [Update]

kde-logo-official
I just watched Mark Shuttleworth’s Keynote on aKademy. The discussion afterwards was mainly dominated by his suggestion to switch KDE’s development cycle to a 6 month release cycle. Here is a closer look at what Mark said – and what KDE did in the past.

What Mark said

It is important to point out what Mark said exactly:

If you guys articulate it and make a commitment to shipping something round about the same time as Gnome did, we would made a converse commitment and that is we’ll ship your stuff very shortly after you do.

It is a promise in vapor ware on both side: the KDE team would promise to ship the next KDE version no matter what it costs, and the same is true for Kubuntu. In this regard the priorities must also be clear:

It boils down to this: No single feature is more important than the release.

It would mean that only these features are included which are really stable enough at that time – everything else would have to wait another release cycle to be included with the next KDE upstream version.

Of course, this would have several advantages and disadvantages:

Advantages

The biggest advantage would be that a recent KDE would be included in each new Kubuntu release: this would give the users a much better experience and it would also mean much faster feedback for the KDE developers. Also, the drumbeat resulting from this release commitment would be enormous: K/Ubuntu, Gnome, KDE, the kernel and maybe even OpenOffice all releasing in the same time frame would create a rhythm hard to ignore. Also, it is likely that other distributions would pick up this release cycle: in these days many of the distributions try to keep a periodic release cycle. And it makes sense for all desktop oriented distributions to take over the release cycle of the main desktop environment. Ubuntu does it, Fedora just stated that they are going to do the same.
It would be easier for the distributions to plan and organize releases, and it would enable them to ship the newest technology available all the time.

Disadvantages

There are mainly two reasons against such a cycle I can think of at the moment: first of all the developers would have to get used to this kind of pressure and rhythm, and they would have to adopt it. New features would have to be coordinated quite exact and new, complex features depending on each other would become quite difficult. This is possible, but requires for example a very balanced and thoughtful release coordination team.
The second reason is press: With the current situation there are Open Source news all the time. But when all projects start to sync suddenly there would be just too much information all 6 month with much less notable events in between. Just imagine the news when KDE and Gnome would release new versions in the same week: “KDE vs Gnome”, etc.
Also, smaller projects would have it difficult to gain enough attention if they would adopt the release cycle (although they would get more if they would a-sync their release cycle).

I’m not sure how the press thing would work out for the different projects – maybe it would hurt them, maybe not. Maybe it would even lead to more attention by broader media (evening news and so on).

What KDE actually did

The question is now if KDE could even adopt such a release cycle. Would the project be able to do such a thing? Or would it be so alien that it could hurt the project?
To answer that question I had a look at the KDE 3 releases:

KDE 3 releases over the time
release number release date time difference to
previous release
time difference
between major releases
4.0 (expected) 23 October 2007 154 days that doesn’t count – but:
693 days, roughly 23 months
3.5.7 released 22 May 2007 117 days
3.5.6 released 25 January 2007 106 days
3.5.5 released 11 October 2006 70 days
3.5.4 released 02 August 2006 63 days
3.5.3 released 31 May 2006 64 days
3.5.2 released 28 March 2006 56 days
3.5.1 released 31 January 2006 63 days
3.5 released 29 November 2005 47 days 258 days, roughly 8 1/2 months
3.4.3 released 13 October 2005 78 days
3.4.2 released 27 July 2005 57 days
3.4.1 released 31 May 2005 76 days
3.4 released 16 March 2005 98 days 209 days, roughly 7 months
3.3.2 released 8 December 2004 57 days
3.3.1 released 12 October 2004 54 days
3.3 released 19 August 2004 71 days 198 days, roughly 6 1/2 months
3.2.3 released 9 June 2004 51 days
3.2.2 released 19 April 2004 41 days
3.2.1 released 9 March 2004 34 days
3.2 released 3 February 2004 20 days 371 days, roughly 12 months
3.1.5 released 14 January 2004 120 days
3.1.4 released 16 September 2003 49 days
3.1.3 released 29 July 2003 71 days
3.1.2 released 19 May 2003 40 days
3.1.1a released 9 April 2003 20 days
3.1.1 released 20 March 2003 51 days
3.1 released 28 January 2003 38 days 300 days, roughly 10 months
3.0.5a released 21 December 2002 33 days
3.0.5 released 18 November 2002 40 days
3.0.4 released 9 October 2002 51 days
3.0.3 released 19 August 2002 48 days
3.0.2 released 2 July 2002 41 days
3.0.1 released 22 May 2002 49 days
3.0 released 3 April 2002

As you can see the time differences between the major releases (3.x) do vary around 8 months. Industry partners need an at least rough release plan, and users are expecting something new every once in a while.
The minor versions where a bit more periodic, but also with huge gaps. However, you could say that there was a minor version every second month.

The major releases vary up to a certain point, but if you only take 3.2 till 3.5 you have a mean of 7.3 months with a standard deviation of 1.32. That is of course not comparable to a fixed release cycle with 6 months, but also not that bad. Neglecting some gaps the minor version also had a release every second months.
Just for comparison: Gnome has a major release every six months. The minor releases seem not to be bound to a fixed date: there were 28 days between 2.18.0 and .1, but 49 days between .1 and .2.

So according to these numbers a switch to a 6 month release cycle would be something totally new for KDE!

Worth a try

Although such a drastic change in preparing releases would mean a lot of change for KDE I think it is worth a try. KDE should work on better release politics anyway to get at least some sort of stability.
Lookin (now) at these numbers it turns out that a switch to a fixed release cycle would require some changes – but not that drastic ones. So from that regard a switch to a periodic release cycle looks at least possible.
There are other possible advantages: it is much easier to talk to corporate users, ISVs and distributors if they can predict the next releases. And KDE has matured enough to listen also to corporate users. And of course: it would be more fun for the users: having a major release in a regular time frame would be more fun to follow. Last but not least it might even attract new developers.

So there are two questions: first, will KDE switch to a fixed release cycle, and second, will KDE switch to a 6 month cycle? But that is up to the developers, they will have the last word. Until now now one spoke out – except Sebastian Kügler, who is opposed to that idea I’m anxious to hear other comments about that topic.

Update:
Kurt Pfeile thankfully spotted a small but important mistake: in the calculations I missed the KDE 3.4 release and calculated the difference between 3.3 and 3.5. This changes the view on the release cycle. The parts in the text are corrected. I’m very sorry for this mistake and the inconvenience it might has caused. I will have an extra look next time I calculate such important dates and time frames. Thanks again Kurt for your remark about that.

About these ads

27 thoughts on “KDE and a periodic release cycle [Update]

  1. That’s some excellent research on the numbers. Shouldn’t the Debian approach be embraced more seriously to avoid bugfixing releases that are so frequent. Even Ubuntu has some bugs, unless it’s LTS. It’s not a good thing. It’s a matter of taste, but less regular releases (upgrade chores) and higher quality have some merits too.

  2. Of course you have to find the balance between new releases (equals new features) and bugfixes. New features are more interesting for the developers, while bugfixing is boring. The kernel had quite some interesting discussions about it.

    And to be honest: I think that the comparison Debian vs Ubuntu shows that the Debian attempt would be the right one bugfixing wise – but in no other regard at all: the development would not be as interesting as before, the users would be more bored, and so on.

    I think the other way would be better: releasing on a fixed time scale, but adding more tests. As it looks like KDE (and most software projects in general) are just at the beginning of using regression tests, Unit tests, etc. You can gain a lot of stability and avoid many stupid bugs by adding such tests – and if KDE (and Ubuntu, btw.) implements more of them the releases would become significant more stable.

  3. Maybe it’s worth it, but if the KDE release is not in the similar pace. If a distro releases at time t, release at t+3months then have 3 months for stabilization.
    This would ensure that the distributions actually get something stable, not something with major/waiting to be discovered bugs in it.

  4. Just like Sebastian Kügler said, if the distributions want to get a recent version, they should help to get the next release ready, e.g. fix bugs etc.

    IMHO it’s not an option at all to distribute a (maybe) buggier version due to stress on the developers or lack of time, which goes hand in hand with stable programs that barely have a part of their planned features. (Not very realistic, but to make it clear…)

    Furthermore, one should not forget those programmers who invest their _free_ time in projects like KDE. You can hardly force them to work faster just because some distro wants to have the new version ready for their next release.
    The distro could as well give a way to upgrade to the next version without /any/ problems and in an easy way.

    This would also minimize bug reports and feature requests due to a more mature version.

    PS. sorry for possible misunderstandings, but my English in not exactly the best in non technical parts

  5. Jan-Hendrik, I don’t think that the fixed release cycle would necessarily put more pressure on the developers: they could work as long as they want on new features in trunk. There would be no force at all.

    Also, it is not said that such an earlier release would be more buggy – since the schedule would be predictable every developer could check previously if a specific feature would be stable enough to include it in the next release – a fixed time for bug fixing already included!
    If the developer thinks that the time is too short he/she simply does not include the feature.

  6. I think it’d just kill innovation.

    Gnome has a period of 6 month but the features offered in each are from my point of view (that is, non technically and from a KDE home user) nearly invisible (Seriously, I don’t mean they are, but as a user I see no big changes form Ubuntu 5 to Ubuntu 7 and their Gnomes).

    KDE has two major groups to target (again, from my point of view): industry and home users (for whom is very suitable). Industry benefits a lot from PIM and semantic desktop and user get attracted by the applications and beauty. The work in those areas is fruit, probably, of the massive work done in the backend engines (am I right?). What would happen to any proposal pretending to modify the “big areas”? Its very probable they will always be delayed or simply ignored because of the release cycle and nor the firsts (industry) benefit from small releases (indeed most of them uses antiquated software, because they just know it works) nor the seconds, that rather prefer visible changes. Just think that KDE4 as it’s shaping now would never be with a release cycle (at least release cycle of less than 1 year)

    Probably KDE has a model to look at at this point in Apple’s MacOX.

    Oh, I’ll go further: Gnome vs KDE is a battle of opposed philosophies. Convert KDE to Gnomes philosophy would kill KDE (I take Linus word here as mines).

  7. Small error there:
    371 days, roughly 21 months
    should be 12 months if the days are right.

  8. Re: Miguel.
    I don’t think those points hold, firstly KDE4 would be an exception to the 6 month rule either way. Its KDE4.1, 4.2, 4.3 that are suppst to be 6 months apart.

    As for the opposite philosophies, Linus’s _masterful_ point wasn’t about release cycles ;) He was talking about usability. Linus dose great rants, they’ve always got very clearly expressed points of view and reasons well worth reading.

    Anyway, on the 6th month issue. I think that a release should be done “when there is something worthy of being released”. If you have nothing important but its 6th months so you release anyway:
    1) Distros have to do packaging, its work for little benift.
    2) Companies have to do spend time makeing a decision about upgrading, time is money.
    3) Companies may have to do upgrade testing and bug testing.
    4) Everyone who upgrades risks an upgrade problem breaking their KDE
    5) The release has to be supported, even beyond the next release (I think that’s how KDE works)

    All these costs are inherent in a release, so it makes sense to limit the number of releases by only releasing when there is something worth releasing. I personally like the Debian model of having release blockers (no release until these are met) and release goals (desired but not required) with a skilled release manager(s) who can keep track of what’s happening and decide when the release happens or call a freeze.

  9. Tortanick: Interesting points, although I think the company parts are not that important because they do rely on long term support distribution releases and do not “see” the fast updates. And the update risk and rebuild problem comes with every new distribution update anyway.

    However, what I’m most surprised about is that now the second person mentioned the Debian way as something good – I would never ever have thought about that!
    For me the Debian release cycle which has years between each release is hostile to the implementation of new features. I doubt that developers want to wait 2 years until their feature really hits the desktops.

    And, things like blockers and release goals as described are at least part of Fedora as well – and I’m pretty sure every other larger FLOSS project has them as well.

  10. I would say that a fixed-release for KDE would be a detriment to quality control. As it stands now, KDE is released when it’s ready, not when a release manager has to tag out for release.

    I would say a better solution for both Kubuntu / Canonical and KDE would be a staggered release schedule whereby Ubuntu is released say, in the first half and Kubuntu the second. That would save on a lot of headaches coordinating releases for the Ubuntu teams at the same time as releasing pressure on KDE to do what’s best for users no matter what it takes. I think a year is a more attainable goal given that KDE is not funded to the same extent as Gnome. Package managers were invented to provide easy upgrade paths for users.

    The same buzz is generated for Canonical, and both desktops have some breathing room to do more than incremental updates.

    If Linux is to attain a reputation as a full-fledged operating system capable of replacing Windows in the minds of regular users, we also need to think about getting away from the one release every six months mentality, which really only breeds the “Linux is something to try out” mindset. If we give the impression that a new install is required every 6 months to a year, it’ll never shake the play-thing moniker. Windows only needs to be installed once, and lasts until a), a reinstall or b), the customer buys a new computer. Canonical isn’t in the business of handing out “Try AOL” disks.

    I would say Apt’s insistence on providing a painful upgrade path to a new release making it easier to just do a reinstall with the latest disc only reinforces this mindset.

    The answer to that as well as a number of technical issues regarding firmwares and after-market package adds and revision issues would be to switch to Portage, Gentoo’s ebuild system utilizing binaries by default.

    1) Firmwares are a pain.
    2) Codecs are a pain, often requiring the installation of a dev system and manual input to install a simple package.
    3) Rebuilding packages that aren’t core is a pain for third-party contributors.
    4) Debs and rpms don’t always match the layout, making source-based install the only option. This is a pain for the novice, but Portage would make such addons a breeze.

    Kubuntu would be my primary distro if this should happen. I desire long-term upgradeability, and Gentoo has that in clubs. I don’t want to do a potentially system-breaking upgrade every few releases just to stay within the package upgrade window.

  11. Liquidat, you clearly have no idea about how the Debian release works at all! I just have two words for you “Debian Testing”.
    Testing is the perfect hobbyists upgrade cycle. A package is tested in unstable then released as soon as it has no known RC bugs to testing. No waiting some 6th months to get something. Debian stable is for a different kind of user.

    You also seemed to have misunderstood my point, What I was talking about is “Releasing when ready”. Rather than releasing when the time is up. I wasn’t saying release every 2 years.

    As for you’re point about companies, you’re probably right about them not noticing, (save a few idiots somewhere, there’s always some).

    James Smith: you’re point about apt is inacurate. Upgrade problems are the fault of bad packagers not apt. I agree with you that the 6th month reinstall mindset is awful, one of the reasons I’m on Debian :)

  12. Tortanick: Since I learned my Linux skills on a Debian machine I think I have a pretty good idea about the Debian release way. And of course I know Debian Testing.
    However, from my point of view Debian Testing and Debian stable are not the way to go for the masses: Debian stable is released too seldom and more important, is not predictable which makes it unsuitable for corporations. And Debian Testing has too many updates for the normal (!) desktop user – these users want to have a stable base at least for quite some time.

    James: Ubuntu offers both: 18 months cycle (at least so its planned) and a 6 months cycle. That is far away from the AOL idea because no one is forced. Still, keep in mind that Linux still has lacks of functions in a lot of areas and therefore need often releases for the people who want to try out the newest things.

    About your major point, Gentoo’s portage: I don’t see the need for it. Everything, even Portage or Apt or yum, boils down to the ability of the written scripts. And they define how well a upgrade is possible or not.
    Of course, how much effort someone needs to write good scripts depends on the platform he writes for – for that reason it needs no effort to mix 32 bit and 64 bit software on yum/rpm based systems while apt/deb still need to hassle around till the next major update of apt.
    However, I don’t see the technical advantage of Portage. Please give me technical reasons why it would be a major advantage over both, rpm based and deb based solutions.
    And, keep in mind that I do not consider self compile as an option in any way for the user. I know that it is easy with Gentoo, but it still requires massive CPU cycles, and that is not an option at all for most users from my experience.

  13. Sorry to say you didn’t understand Debian release cycles. I still disagree with you though, currently most debian desktops run testing or unstable so developers are not waiting 2 years for feedback.

    I also disagree about corporations wanting predictability, firstly they don’t get that from windows, look at Vista. In comparison Debian uses physic future sight to chose release dates. And secondly most corporations tend to be a few years behind the technology curve anyway.

  14. Tortanick: I think the fact that most people run Testing just shows the problems Debian has. In theory Testing was never thought as what it is today afaik.

    And about the corporations: I think they would appreciate if there would be predictability because then they could start planing the IT world. With Microsoft that was impossible, with Linux it is. But you’re right about the fact that most corporations are behind the technology…
    I don’t have enough inside into different corporations to be really sure about such things, so maybe you are right… I would like to see a study about that, might be an interesting topic.

  15. Of course the 6-month release cycle has a few good points but of course in general it’s just Mark saying “please change all software to revolve around Ubuntu releases”.

    A few other quick points:
    * With regard to biarch-compatibility for Debian-based systems, this would have to be done at the dpkg level (not just with an apt release), and though there’s some talk about it, a lot of Ubuntu developers I’ve spoken to think it’s “not worth it”, which is a bit of a shame really. It will be interesting to see how things change over the next year when people start getting 4Gig of RAM and start thinking about more.

    * The main selling point for corporations isn’t always a _predictable_ release cycle (though this is a plus; in the real world delays happen, even for Ubuntu despite promises), but also long release cycles. Dell, Sony etc _love_ it that MS makes a release every 5+ years or whatever.

    * Ubuntu’s LTS releases can’t really be seen as an “18 month release cycle”. Upgrades from one LTS release to another one are _completely unsupported_ and are pretty much guaranteed to break because of apt. apt is very quick, but libapt is hard to work with, and apt itself makes notoriously dumb decisions (and needs a guiding manual hand a lot of the time), which makes it a lot of extra work for developers to support upgrades. IME, skipping upgrade versions with i.e. openSUSE or Fedora tend to work a lot better (though it would be interesting to see how an ubuntu upgrade goes with smart).

  16. The upgrade between LTS versions is not supported? That’s new to me, I always thought they would be…

    I mean, although I never really checked I think that an upgrade from RHEL 4 to RHEL 5 or SLED 9 to SLED 10 is supported – or am I wrong here?

  17. Liquidat, when you say that the high use of testing just reflects the problems in stable (I’ll take you’re word for it), I say that the users discovered something the devs didn’t: the joy of stable rolling releases. As a result the devs have learnt from the users and are actively improving testings capabilities as a desktop. For example they created the testing security team. And don’t forget the popularity of unstable ;)

    Frances, where did you get you’re information about what companies like? I’d be interested in reading it.

    As for biarch compatability in dpkg, did you talk to the Debian Developers? I’d imagine they’re far more interested in that sort of thing.

  18. Tortanick: I wouldn’t that much surprised if some day the Debian developers would switch the name from Testing to “Desktop” or something – because most Debian people I know use it exactly in that way, while stable is for the server.

  19. Sorry, I think the “release every 6 months regardless” is a fast track to getting the reliability and bug fix frequency of Windows.

    There is a reason linux has historically “released when ready” … so that when something IS released, it’s bulletproof. Look at where some of the Ubuntu releases have been for stability when they force a release date … Dapper was pretty good, but there were some horrors from later releases which I feel were rushed out to meet some intangible, made up release deadline.

    Put out quality software when it’s ready … not when some date is circled on the calendar. Protect the open source reputation for security and stability, or we’ll just be using a free substitute for all those Windows bugs and crashes.

    Just my 2 cents.

  20. I pretty much agree that a fixed timed release of KDE would not be all that great. The Debian release cycle can be a little long in the tooth, so this not a great example either. Any distro worth their salt would include it in the next release anyway, maybe in the repository (generally speaking) before the next release. So… I would say keep it like it is. Maybe feed some morsels from the next release periodically (back porting).

  21. Henaway: AFAIK Microsoft releases Windows “when it’s ready”, I don’t remember a 6-month cycle in Windows. So I don’t see how KDE could get closer to Windows buginess when they adopt a totally different model. Don’t forget, it’s not just the release model that helps fix bugs – it’s the openness of the code as well.

    This argument practically boils down to “evolution (small steps) vs. revolution (big steps)”.

    The main argument against the “evolution” (fixed) release cycle is that big rewrites won’t happen very often, features get included one by one (we have neither GNOME 3.0 nor Linux 3.0).
    The main argument against the “when it’s done” (big steps, with no time set) release cycle is that the code won’t stabilize for a long time ( there is no stable Enlightenment 17).

    To me, the most logical thing is to combine those two principles – that’s what both Linus and GNOME are doing (the question is, when will work on Linux 3.0 and GNOME 3.0 start).

    I’d suggest releasing big rewrites (KDE 5.0, KDE 6.0) when they are stable enough – when they are done. On the other hand, the minor, more frequent releases can be made on a fixed date, for example once or twice a year. It would make life easier for the package maintainers (and upstream needs them as much as they need upstream, so both sides should work and think together).

    Some people here say it would kill innovation, but I don’t see how – the kernel developers don’t seem to be complaining much about innovation loss. Minor “sacrifices” to innovation are always made to ensure stability, but your feature can wait a few months, I am sure.

    Just my 2 cents.

  22. Nobody seems to have looked closely onto your table.

    Otherwise they’d have noticed the error you made when calculating the 3.4.0 and 3.5.0 release cycles.

    Please correct this.

    (….and suddenly the difference goes down from min/max=198/467 days to min/max=198/258 days.

    Here goes your conclusion about “massivley varying time differences between the major releases (3.x)”; it became completely invalid now.)

  23. Liquidat:

    “However, I don’t see the technical advantage of Portage. Please give me technical reasons why it would be a major advantage over both, rpm based and deb based solutions.
    And, keep in mind that I do not consider self compile as an option in any way for the user. I know that it is easy with Gentoo, but it still requires massive CPU cycles, and that is not an option at all for most users from my experience.”

    -Add-on package maintainers now have to worry about packages not working across releases; with a build system in place, package maintainers only need to do one ebuild release for all Ubuntu releases. As mentioned, great for firmware and multimedia codecs. One doesn’t need to rebuild different revisions for each Ubuntu release.
    -The default is to use only binaries for Ubuntu, and packages are pulled down from repositories based on the ebuild. If one absolutely requires source-based, to use for example USE flags to make a tight deployment on server hardware, it’s easy enough to do. This would seriously change the mindset of Ubuntu being strictly a desktop / tryout distro and make it a serious contender for datacentre use.
    -Ebuilds are long-term. I’ve run Gentoo for close to 3 years without a new install. It’s a pain to do a distro upgrade when the release already includes a package manager. Especially with binary-based builds like .rpm and .deb, as they follow releases and drop off when no longer supported.
    -I can see a modified Kdiff for example being used in concert with Kuroo to provide config updates to ensure a more seamless upgrade.

  24. Kurt: Thanks for spotting that mistake. I’m sorry for that. And of course you are right, now the conclusions are different, the release cycle does not differ that much anymore.

    James:
    1) The cross release thing is not that different between dpkg/rpm distributions and Gentoo: if there is no need to rebuild something it will not be rebuild. In fact, in case of Fedora I maintain a single spec file (a rpm recipe) for all Fedora versions which include my program. So there is no need to have different build versions. As an example the rsibreak package I created once for Fedora 6 is used in Fedora 7 as well – and will be also shipped in Fedora 8 if there is no reason for a rebuild (which would be: an update or a switch of the base system to for example a new compiler generation or something like that).

    2) Ubuntu is not desktop orientated – it has a server version as well.
    Also: Red Hat and SLES are used in large data centers and these are not source based as well.

    3) This argument uses the source argument – and self compile is not an option for the masses. Not at all. So if that is the only solution we cannot solve the problem for the masses. However, if the distributions would actually really support updating without re-installing (Fedora does support that partly by using the install-CD to update) this might also be possible – it is a question how good the scripts are. And they are not that good because this way of updating was never (afaik) a major priority of the distributions. It is possible btw. with SLES and RHEL (where people really focus on that issue I guess).
    But what I do not understand: you say the pain comes with the package manager, but what about portage? (this might be a definition problem, I don’t know).

    4) I’d like to focus on the average user – no average user can handle diff output. RPM also has ways to ensure at least config file changes do not get lost – but that is simply not required for average users.

Comments are closed.