Linked by Thom Holwerda on Tue 29th Jul 2008 20:39 UTC, submitted by vege
KDE Earlier this year, the KDE team released the highly-anticipated 4th major revision of the KDE desktop. Instead of bringing evolutionary changes, KDE 4.0 effectively delivered a complete rewrite of KDE, and as a consequence the first release of the KDE 4 branch lacked a lot of features of KDE 3.x, while also being quite unstable and rough. Many even complained the KDE team shouldn't have released KDE 4.0 as 4.0, but rather as a developer preview release or something similar. During this storm of criticism, the KDE team calmly pointed out that KDE 4.1 would fix many, many of the issues people had with KDE 4.0. Starting today, there's no more pointing towards KDE 4.1: KDE 4.1 has been released today.
Thread beginning with comment 325276
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Don't look back
by Richard Dale on Fri 1st Aug 2008 12:19 UTC in reply to "RE[7]: Don't look back"
Richard Dale
Member since:
2005-07-22

We are arguing at cross purposes. I do not consider "getting your libraries sorted out" at all to be a thing worthy of release. You work bits of that as you need it, letting user stories drive the requirements.


No the design of KDE 4 was not driven by 'letting user stories drive the requirements' because we aren't developing business applications. Amongst other things the KDE team is developing a framework that you could develop business applications with. But that is a very different process from developing the business applications themselves.

You can see this on OSX releases, Core* overhauls have been spread out over about four releases, each release taking the one or two core libraries implemented in that release, and giving real world value to the users, and never pushing their release cycle over 6 months, or reducing existing functionality.


Apple has beta releases for developers 6 months or more before they have a corresponding release for end users. That is because the developers have to write applications before the users can use them. KDE doesn't have the same system, but the KDE 4.0 release was intended as a release for developers to write applications against the new libraries. Whereas KDE 4.1 is more like a first user release in terms of Apple's release strategy.

What KDE did was basically a Vista on a smaller scale, bit off way more then they could chew, being forced to ship something that had drastic changes that noone will care about for awhile till everything else catches up.


No that's completely wrong, and you don't appear to have understood how the KDE development process works in spite of some excellent efforts by Boudewijn Rempt, Segundum and others to explain it to you.

In my team, we adhear pretty closely to the Scrum process. If we end a release cycle without anything of business value to show the share holders (our users), we consider that iteration to be a failure, and try to figure out where we went wrong. If we ever blew a deadline by four months and released something that was buggier and less functional, that would be considered a failure of epic proportions, and our project manager would probably lose his job.


Your team sounds like a relatively small group developing business applications, and that is in no way comparable to the KDE project. KDE doesn't have 'deadlines', 'share holders' or 'project managers' who may or may not lose their jobs. Any comparisons are pretty meaningless.

Reply Parent Score: 2

RE[9]: Don't look back
by google_ninja on Fri 1st Aug 2008 13:01 in reply to "RE[8]: Don't look back"
google_ninja Member since:
2006-02-05


No the design of KDE 4 was not driven by 'letting user stories drive the requirements' because we aren't developing business applications. Amongst other things the KDE team is developing a framework that you could develop business applications with. But that is a very different process from developing the business applications themselves.


So essential KDE design is driven by developers, not users. I don't think that makes sense when your goal is to create a product for users, but that is just me. It makes sense when you look at the way the team acts.

Apple has beta releases for developers 6 months or more before they have a corresponding release for end users. That is because the developers have to write applications before the users can use them. KDE doesn't have the same system, but the KDE 4.0 release was intended as a release for developers to write applications against the new libraries. Whereas KDE 4.1 is more like a first user release in terms of Apple's release strategy.


In the case of gnome or the kernel, even versions mean stable, odd mean release. That is not the case of KDE. Again, this only makes sense if developers are driving the design.

Your team sounds like a relatively small group developing business applications, and that is in no way comparable to the KDE project. KDE doesn't have 'deadlines', 'share holders' or 'project managers' who may or may not lose their jobs. Any comparisons are pretty meaningless.


A team whose goal is to deliver high quality software to users will always have certain things in common. Replace deadline with goals, and project managers with "people who direct dev effort on the team". Share holders or product owners is just another word for user, but words that keep you thinking of them as your boss rather then something you have to put up with.

Honestly, if the reason that KDE4 was what it was is that the KDE developers don't see anyone but other developers as their end user, it would explain alot. That kind of is at odds with the linux evangelism effort though, which typically claims that open source software is just as good as commercial software for home users. It never will be if the development process is not engineered with that in mind, plain and simple.

Reply Parent Score: 1

RE[10]: Don't look back
by Erunno on Fri 1st Aug 2008 16:44 in reply to "RE[9]: Don't look back"
Erunno Member since:
2007-06-22


In the case of gnome or the kernel, even versions mean stable, odd mean release.


The kernel dropped this versioning scheme (and development model) beginning with the 2.6 series. Each release (even and uneven) is considered stable. There has been talk about changing the versioning scheme altogether to reflect the fact that there never will be a 2.7 or 2.8 kernel.

Reply Parent Score: 2