The benefits of a regular release schedule
I have recently read the announcement that Kubuntu 8.04 is NOT going to be an LTS release, thereby deviating from the release schedule of all the other Ubuntu variants. I believe that it would be more beneficial to synchronize the LTS releases between the official Ubuntu variants.
First of all, Ubuntu needs to solidify its public image as much as possible. This is even more important while it has such a small mind-share in the overall technology market. Most computers users have no idea what an LTS release is, and they could be confused by mis-matched numbers. "Why is Ubuntu 8.04 LTS and Kubuntu 8.04 not LTS? Why is Ubuntu 8.10 not LTS and Kubuntu 8.10 is LTS?" Some IT departments might choose to only support LTS releases of Ubuntu. Now they must work with their KDE users who would need to upgrade on a different schedule than their Gnome users.
I understand why Kubuntu wants to delay their LTS release. They have a shiny new version 4.0 that provides many new features, but it is not quite ready to be considered for an LTS release. Historically, the last LTS release (Ubuntu 6.06 LTS, Dapper Drake) included primarily minor changes that focused on stability and polish. For Kubuntu 8.04 to be an LTS release, it would need to stay with KDE 3.5. No major changes should be made during an LTS, which I think everyone agrees upon.
The unfortunate timing of a moving KDE 4.0 release date is a problem that can be corrected. Mark Shuttleworth suggested at the last aKademy conference that KDE should change its release process to a hit a regular schedule. You can view the video of Mark's keynote address on the web. The idea is a simple one: Set a hard date and modify your goals (features) to match that timeline.
This sage advice was not well received, but it should be taken to heart by KDE. I believe that it would tremendously benefit KDE to create a regular and predictable release schedule. See the benefits that this has had for Gnome and Ubuntu. When open source projects have dependencies with each other, a regular release schedule allows them to plan their releases better. For instance, Ubuntu trusts Gnome to hit a stable release on time so Ubuntu provides them more time before freezing changes.
Now consider the negative aspects that an unpredictable release schedule brings. The best example of this is how users left Debian for Ubuntu so that could get an OS that provided regular releases. Another example is how the release of Microsoft Vista slipped multiple times, throwing off the plans of IT departments, software development companies, and computer vendors. A predictable release allows external parties to prepare and plan for the release. If KDE does this, they too will reap the rewards that Ubuntu has seen.
First of all, Ubuntu needs to solidify its public image as much as possible. This is even more important while it has such a small mind-share in the overall technology market. Most computers users have no idea what an LTS release is, and they could be confused by mis-matched numbers. "Why is Ubuntu 8.04 LTS and Kubuntu 8.04 not LTS? Why is Ubuntu 8.10 not LTS and Kubuntu 8.10 is LTS?" Some IT departments might choose to only support LTS releases of Ubuntu. Now they must work with their KDE users who would need to upgrade on a different schedule than their Gnome users.
I understand why Kubuntu wants to delay their LTS release. They have a shiny new version 4.0 that provides many new features, but it is not quite ready to be considered for an LTS release. Historically, the last LTS release (Ubuntu 6.06 LTS, Dapper Drake) included primarily minor changes that focused on stability and polish. For Kubuntu 8.04 to be an LTS release, it would need to stay with KDE 3.5. No major changes should be made during an LTS, which I think everyone agrees upon.
The unfortunate timing of a moving KDE 4.0 release date is a problem that can be corrected. Mark Shuttleworth suggested at the last aKademy conference that KDE should change its release process to a hit a regular schedule. You can view the video of Mark's keynote address on the web. The idea is a simple one: Set a hard date and modify your goals (features) to match that timeline.
This sage advice was not well received, but it should be taken to heart by KDE. I believe that it would tremendously benefit KDE to create a regular and predictable release schedule. See the benefits that this has had for Gnome and Ubuntu. When open source projects have dependencies with each other, a regular release schedule allows them to plan their releases better. For instance, Ubuntu trusts Gnome to hit a stable release on time so Ubuntu provides them more time before freezing changes.
Now consider the negative aspects that an unpredictable release schedule brings. The best example of this is how users left Debian for Ubuntu so that could get an OS that provided regular releases. Another example is how the release of Microsoft Vista slipped multiple times, throwing off the plans of IT departments, software development companies, and computer vendors. A predictable release allows external parties to prepare and plan for the release. If KDE does this, they too will reap the rewards that Ubuntu has seen.
Actually it was Canonical who decided that Kubuntu won't be an LTS. The Kubuntu developers had no say in it. They were only informed about the final decision.
ReplyDeleteAnd it's not just Kubuntu who won't have this tag - I'm not sure Edubuntu, Xubuntu or other releases will be having an LTS release.
It may be that Canonical wants Kubuntu to invest more time into KDE4. It could also be that Canonical wants to promote Ubuntu commercially more at the expense of denying the same right to the now "pseudo"-officially supported Kubuntu. Or there may be another reason. Who knows?
An official statement from a Canonical employee who decided it would clear up the confusion. There are many questions that are popping up:
Is Canonical throwing Kubuntu into the community-supported-only-not-good-enough-for-businesses waters? Can we make Hardy+1 or +2 an LTS, when KDE4 will be stable enough? Is there going to be an LTS of Kubuntu in the future?
I can ask someone personally, but I'd prefer to have a public FAQ regarding this decision.
I think it's a really stupid idea. KDE 4 is being heavily rushed. The so called "Release Candidate" is only alpha, or at best, beta quality. I absolutely hate it when point-zero software is released; it makes people go insane. IMO, Kubuntu should be released as an LTS with 3.5. Version 4 shouldn't even be an option yet. I'm sorry, but it just isn't stable and KDE 4 isn't the cure for cancer nor will it solve world hunger. There is nothing wrong with waiting until 8.10 to make a release with KDE 4. If people want KDE 4 sooner than that, then they can use an unofficial repository, but pushing such incomplete software on average, non-technical users is poor decision.
ReplyDeleteCome on guys! Change the 'mind set' and establish a goal based on 'standards' and not one based on 'time.' If you establish a standards based goal, you are going to end up with a better product, ready for release, and that 'works.' When you develop on a 'time based' standard, you are forcing yourself to (most likely) release a product that may not be ready for prime time.
ReplyDeleteA lot of people who have never used Linux are coming over from the Windows community. If their first experience with a release is 'less than favorable,' what have you accomplished?
A Quality based standard should be preferred to a Time based standard.
What Anonymous said is not "untrue", but...
ReplyDeleteThe write is talking about a time-release schedule equal to the one Gnome uses. This means that at the time of the freeze only the new stuff is included that is stable enough, the other parts will wait until the next freeze.
I also agree that a gnome-like release schedule is the best for all. And please, do not compare it to the Ms release schedule. If those would be our standards in Linux... (nevermind)
I think there is worth in both approaches. I think regular releases are especially important for minor releases. One of the reasosns why I switched to Foresight Linux because Fedora always pushed releases and so I could never be sure when to get it. Same is true for upstream projects like KDE - if I exactly know I will get a new version next week - and only maybe I wont get feature X that is ok for me. I will still be able to checkout a feature from SVN if I really desperately need to. Also one can establish a new common base on which developers and users work (and therefore a user might not have to start a new app, because a software now has the feature he needs). Releasing is a way of communicating. Its also important to have some major goals and to not look at release cycles uppon them. But for the every day release work I think regular cycles are a good thing.
ReplyDeleteI might have misunderstood the post on kubuntu not being LTS, but I think it's refered to kubuntu with KDE 4. The kubuntu 8.04 release with KDE 3 will be LTS. Am I wrong?
ReplyDeleteEdmundo Carmona
I agree that KDE should adapt to a fixed release date schedule. Moreover, I believe even the smallest open-source project should synchronize its releases with big ones. If all open-source projects can stick to a fixed date consistently, this creates something that is extremely valuable for the business world: predictability and thus lower risks. This will improve the image open-source a lot...people will not be able to assume any more that open source is amateurish and that closed source software is professional. If the consistent fixed release cycle gets popular, it'll be the closed source software that will be seen as amateurish...
ReplyDeleteThat does not mean software projects should switch to 6-months release cycles! They can do as many releases in a year as they want...as long as they stick the release date of these releases (or release) with the 6-month cycle dates of the 'big projects'.
The Coccinella project (that includes me) issues 4 or more releases each year, so we have something like a 3-month release cycle. We do 2 of these releases at (or a day before) the day a new Gnome version is released. The other 2 or more releases are more flexible, but they will be on average around 3 months after the fixed release. More releases are possible when we do important bug fix releases e.g.
I can assume some projects only release once a year or even less. In such a case it would be good if they also could stick that one release to the same date as the 6 month release cycle of Gnome.
PS: I'm a KDE guy, I never use Gnome.
I have to say I think you're dead wrong.
ReplyDeleteYou say "Look at how many people left Debian for Ubuntu's regular release cycle" but I say "Look at how many enterprises use Debian because it doesn't contain more bugs than a ghetto kitchen".
Predictable release cycles do nothing but give people a false sense on stability sicne you said it yourself - make your goals fit the time frame. When you really think on this, how can you meet your goals if you're not actually setting them? How can they be set if, a week from your deadline, you have to drop them?
The Vista delay didn't "upset" IT managers - anyone who's been involved with managing IT knows that the minute you change from the default "all bets are off" anyway - despite LTS releases, Ubuntu still has a "Universe" which doesn't get full workovers and since default installs of Ubuntu don't meet everyone's needs immediately, you end up pulling in "unsupported" software anyway.
I dread major upgrades - inveritably interfaces change, there are new features to learn to use, and something you relied on vanishes. This is the drawback of "change" which is why when I have to change, I'd rather the change be "better" than "on time".
People didn't leave Debian for regular release cycles, they left Debian for a distro that focused on the needs of home desktop users rather than being a good basis for a Free Software system.
@Kevin Dean: the whole idea of this fixed releases dates is not about doing unstable releases on a fixed date. Instead, the idea is that you tell to to outside world: "On this date we will do a stable release. You can already do your planning in advance if you want to deploy this release. There will be no delays. You can hire additional people for this deployment in advance as there *will* be a stable release on that date. What we can't guarantee is that all items we had on our roadmap will be in that release; our focus is to make a stable release on that fixed date and all things that are not yet stable will be delayed to a later release. If there is something in this roadmap you really need in your company, you should verify in the beta releases if this feature is stable. If it is not and the feature is very important for you to be in the upcoming release, you should contribute your patches or pay people to get the specific feature stable in time". So, as you can see , it's the *process* that will get stable and this is unique in the IT sector where it is common that software releases are delayed. With fixed dates, companies can plan deployments of new software versions *years* in advance which is a *valuable* asset!
ReplyDeleteThe Kubuntu debacle, shows why Shuttleworth style "predictable" release dates are broken.
ReplyDeleteIf Canonical, can't provide LTS to a "stable" desktop that's been around a long time, like KDE 3.5.8 that is *not* getting new features, what can they provide LTS for?
The clear message is, Cannonical back GNOME and KDE is a 3rd class citizen.
Shuttleworth is out of order, if he's trying to tell KDE how to move their project forwards. If he wants to influence that, he has to support KDE developers, and KDE much better, so they have more concern for his short-term requirements.
The whole point about KDE 4, is that it's a Major version update, aka a re-write of very many features to use Qt4, and re-engineer the destkop environment.
That is not something that the small minded soots, with their nice little charts and planners can control. The project is too big, and the changes too sweeping.
KDE 4 should be released when it's ready for use, it already has less functionality than KDE 3.5.8, due to things like Plasma replacing Kpanel.
The right solution, is to provide KDE4 alongside KDE3, and let admins and users migrate over, when their applications and needs are better met by KDE4 than KDE3.
This happens to be what OpenSuSE 10.3 already does, which is the reason you don't hear any angst coming out of the OS community. SuSE provided destop updates in past for KDE, for users wanting the latest & greatest, may be their experience is actually showing here.
If you're an end-user then of course you like "predictable" release schedules, just like you would like not to pay taxes.
But there's no point in having a KDE 4.0, if due to release schedule constraints, it is actually KDE 3.5.8+, and lamb dressed as mutton.
"The Kubuntu debacle, shows why Shuttleworth style "predictable" release dates are broken."
ReplyDeleteWhy is that a proof? KDE never said it would adopt the predictable release dates...not yet.
"The clear message is, Cannonical back GNOME and KDE is a 3rd class citizen."
Indeed, but I don't see why this is relevant...
"Shuttleworth is out of order, if he's trying to tell KDE how to move their project forwards. If he wants to influence that, he has to support KDE developers, and KDE much better, so they have more concern for his short-term requirements."
Why needs Shuttleworth to support this? The idea is just that the projects *themselves* *independently* do this. It worked for us at the Coccinella project without any support from Shuttleworth...in fact Coccinella is even not part of any Ubuntu flavor!
"The whole point about KDE 4, is that it's a Major version update, aka a re-write of very many features to use Qt4, and re-engineer the destkop environment."
Indeed, but that's also no excuse for claiming the fixed release dates does not work. If the KDE project would have said it would adhere to the fixed release dates and then not being able to release at that date, it tells more about a poor project management. Oh yes, I'm a *KDE* fanboy in case you thought I wanted to start a KDE/Gnome flamewar...
"KDE 4 should be released when it's ready for use, it already has less functionality than KDE 3.5.8, due to things like Plasma replacing Kpanel.
The right solution, is to provide KDE4 alongside KDE3, and let admins and users migrate over, when their applications and needs are better met by KDE4 than KDE3."
IMO the right solution for the delay issue would have been to not postpone the KDE4 release with 1 month, but instead postpone it with 6 months *and* do a full freeze of the KDE4 branch for 1 month. This 1 month then should then have been used to get more features to the KDE 3.5 branch. After this 1 month lots of patches will be waiting to get into the KDE4 branch so that it will be possible to do a beta/alpha/RC/whatever release short after this 1 month period. The advantage is that there will be a longer testing period for KDE4, more features will get in KDE4, KDE4 will have more features than KDE 3.5.x, and users will get 2 very good KDE releases.
"But there's no point in having a KDE 4.0, if due to release schedule constraints, it is actually KDE 3.5.8+, and lamb dressed as mutton."
I agree, but IMO it would have been better to postpone the KDE 4.0 release even longer and do a more extended 3.5.8+ release instead.
PS: my analysis of why the KDE project did not (yet) adopted the fixed release cycle is probably the large influence of SuSE/Novell and Mandriva in the KDE project. They fair *Ubuntu and thanks to the short delay of KDE 4.0 they have an advantag of 6 months as there will be no LTS of next KUbuntu whilst they can do an 'LTS' release with KDE 4.0 included (they provide long term support for KDE 4.0 sooner as they employ several key KDE devels whilst the KUbuntu project/Canonical doesn't to the same degree).
If Novell, Mandriva, amongst others really influenced (by their contributions e.g.) the KDE project to delay KDE 4.0, it is really stupid. Ok, in the short term it may be good for these companies, but a common, fixed and synchronized release cycle would transform the open source community and the companies around it in some kind of cartel (like OPEC for oil) which will make it easier for the whole group to compete with non-open source software...
KDE should not adopt the fixed release cycle to please Shuttleworth, but because it is in its own self-interest in the long term.
KDE's been going a long time, and it's had a traditional approach to version numbering.
ReplyDeleteJust because Shuttleworth likes a time based release date, doesn't make it right.
There's not a "proof", but it's a complete mess.
Kubuntu won't be taken seriously because of this.
You don't seem to understand the word "if". You may like pronouncements, and agree with Shuttleworth but others are free to do things in the way that has served most development cycles best.
Evolutionary uprades and small steps, may suit release dates, but re-developments don't. It's ridiculous to start saying the KDE project should go with that method, when it obviously won't work.
They have enough trouble with KDE4.0 release as it is without imposing artificial deadline, dropping the newly developed stuff just to get something shipped on time.
"Evolutionary uprades and small steps, may suit release dates, but re-developments don't. It's ridiculous to start saying the KDE project should go with that method, when it obviously won't work."
ReplyDeleteExplain me why 'obviously'? It works for us great with Coccinella and the Gnome people also do not seem to have any trouble with it. Agreed, it will require a change in the KDE project, but claiming that the KDE project is not able to undergo such a change is a bit too pessimistic I hope.
@TheGZeus: the keynote of Shuttleworth was before the KDE project delayed the KDE 4.0 release with 1 month. I also agreed before this delay that KDE 4.0 should not be 'synchronized', but when they delayed the release with 1 month because it was not ready yet I changed my mind. They should have took this opportunity to delay the release with 6 months to get a rock-solid release (I'm hearing stories that KDE 4.0 is not that polished yet... :-( ).