Here’s what Aaron Seigo is saying about KDE 4.0 (source: http://aseigo.blogspot.com/2008/01/talking-bluntly.html):

———–
Ah, the “until it’s ready” idea. Some would say 3.5 isn’t ready; software never really is from a perfectionist’s standpoint. It’s so complex and full of ever springing promise that one can never reach that point of perfection; usually we are just happy with “better than good enough” and call it a day at that point.KDE 4.0 isn’t yet “better than good enough”; so why don’t we just release more betas? When one perpetually releases alphas/betas a few things happen: people don’t test it aggressively enough, third party developers don’t get involved, core developers continue doing blue sky development rather than focusing on release qualities. Between the rc’s and the tagging of 4.0.0 the number of reports from testing skyrocketed. This is great, and shows that when I assert “people don’t test when it’s alpha or even beta” I’m absolutely correct. This is not about tricking people either: people seem to forget that the open source method is based on participation not consumption. So testers look for a cue to start testing; that is their form of participation. “alpha” and even “beta” is often not enough of a cue, especially today when so many of our testing users are not nearly as technically skilled with the compiler, debuggers, etc as the typical Free software user was 10 years ago.

The KDE4 libraries are ready for application development, as testified to by the quality KDE4 apps that exist today. However, third party application developers tend to be a conservative lot, and rightly so. They wait for user base migration, they wait for stability in the APIs, etc. They want to know when to start working with the new awesomeness, and for most of them that isn’t “alpha” or “beta”. The libraries crossed that stage in quality and reliability many months ago and so it is only fair to mark them as such.

Finally, the amazing maturation at all levels of KDE 4.0 software that has happened since the last beta shows just how focusing developers off of blue sky development and onto release quality code is important. The delta speaks for itself.
————–

Of course, the reason why I mention this here is because I strongly disagree with this. I refrained myself from commenting on the labels used by the KDE 4.0 releases by the past but after reading this I would like to intervene. BETAs are tested by the community, I’ve released enough BETAs to appreciate the feedback and the level of testing that was going on. Recently we’ve even released an ALPHA, and that also did get tested very well.

The matter here is to call a cat a cat. If something is labelled as being STABLE then I want to be able to use it as my main desktop, I want to be able to recommend it to people, I want to be able to trust it. If it’s full of bugs, and even worse… if it’s not finished (because that’s what we’ve seen here with the so called Realease Candidates) then there should be some indications of this. I could use the same argument and label our Fluxbox Edition “KDE Edition” so that people try it more than they do now. This is ridiculous. It’s ok to release technological previews, but they should be called previews… and we have a name for this –> “ALPHA”. It’s ok to release non-tested software once you code-freeze and again we have a name for this –> “BETA”. An “RC” should be almost the same as going STABLE, the code should have been frozen months ago, all features implemented, fully tested and with absolutely no known bugs. Calling an ALPHA release an “RC” so that people download it more and perform more testing on it is simply ridiculous. It deserves to be mentioned and criticized. This hurts credibility and it’s a pity for one if not the most popular among our Linux desktops.

I couldn’t understand how RC2 wasn’t labeled “ALPHA”, and I find the justification even worse. I’m being blunt as well and I’m sorry if I’m offending anyone. KDE is probably the most popular desktop within the Linux community, it’s got a great line of 3.x releases and from what I can see 4.x looks extremely promising, why would the devs compromise themselves and hurt their credibility on this? Are they under some kind of pressure? I can’t wait to see KDE 4.0 become stable but you’ve scared me so much with these “RC” alphas I’m wondering if the name for KDE 4.0 stable isn’t simply going to be “4.1”.

What do people think? Am I over-reacting on this? There was a discussion on the Linux Action Show and a KDE dev was justifying the labels by saying that the libs themselves were of RC quality. We’ve been postponing our KDE Edition so much and for bugs that were so small people would hardly notice, but hey.. there’s no lobbying or angry bosses telling us we need to release yesterday, so why not just release “when it’s ready?”. What’s so wrong with that?

Apologies to Aaron and the KDE Team if that is seen as an attack. You’re in charge of a beautiful project and if I wasn’t passionate about this I wouldn’t start this discussion.

Clem

Linux Mint has a very good reputation and we should be happy about this. Most reviews say it’s stable, easy to use and a very good desktop operating system. But when you ask somebody to summarize their opinion on Linux Mint they very often say it’s Ubuntu with all the handy proprietary stuff on top of it.

Unfortunately most reviews focus on how great our multimedia support is and how well Linux Mint can play DVDs and online content… something any Ubuntu, Fedora, SUSE or Linux user in general can add to his/her distro in more or less 5 minutes. This is not an achievement of course and if our only purpose was to be “Ubuntu + codecs” our latest release would have been Barbara.

Some people are even amazed that we release a Light Edition. Understandably, if to them our only achievement is to add codecs on top of Ubuntu, then what difference would there be between our Light edition and Ubuntu itself?

If you asked me what the added-value of Linux Mint was, I wouldn’t even mention codecs. I would tell you about how we changed the Gnome desktop and developed tools to make the user experience easier and more productive. I would tell you how we constantly think of how to improve the system from a user’s point of view and how we’ve done so release after release.

Of course you could run Daryna and use it the exact same way as if you were using Gutsy… tweaking sources.list and using APT, taking your updates from synaptic, sending large series of files through email..etc. We can’t expect everyone to read our release notes and to know about the particularities of our distribution.

What’s even more frustrating is to see Mint users use Linux Mint without making the most of it, and this is one of the reasons why a user guide is being written at the moment.

We’ve got the wrong image, one of a non-free distribution which added-value has to do with codecs and non-free software, when our real focus is on the desktop and on the user experience.

It will take time before people realize what we’re doing and what we’ve done, and it’s very frustrating at times to see our distribution so successful but not always for the right reasons.

To all reviewers: Mint doesn’t come with the so-called proprietary drivers, it barely contains a few non-free components (flash, unrar, w32codecs… hmm.. let me see, is that it?) and multimedia codecs definitely isn’t what we’re focusing on most of the time. It’s these little “open terminal” and “delete” options in the context menu you should focus on, the fact that we come with ndisgtk and have ipv6 disabled to make your ipv4 requests faster… these are the things we focus on. And even without looking at the details the added-value of Linux Mint is to produce tools and in a very general way to make typical user-scenarios as easy and comfortable as possible. We see something hard for the user, we simplify it.

It’s frustrating and I’m a little frustrated by this. The purpose of Linux Mint has never been to add codecs to Ubuntu (that’s what automatix and easyubuntu are for), it has always been to produce a great desktop operating system.

You can notice how the Light edition is using Ubuntu but not the codecs, and how the Debian ISO is using the codecs but not Ubuntu… the goal here is to produce an elegant desktop OS, it doesn’t matter whether it’s with codecs or with Ubuntu or with anything else, these are components in the equation and our focus here isn’t Ubuntu, or the codecs, or to argue between Free and Non-Free Software and whether we should boycott Flash and all… it’s quite simply to get closer and closer to our idea of an ideal desktop operating system.

I was very excited to release Bianca, Cassandra and Daryna because each time I thought our desktop just got way better. The codecs have been the same since we forked from Edgy.. nothing terribly exciting about that..

Clem

While most of us are content with the Main and Light Editions, eagerly waiting on the next XFCE or KDE Community Editions, being seduced by the latest Fluxbox CE BETA or simply having fun with the Debian Testing based ISO… two brand new editions are being developed at the moment.

The miniCD CE is developed by Blahblah_x in the USA. It comes as a 350MB ISO which can be burnt on a miniCD in order to be able to fit in your wallet. It uses the Gnome desktop and comes with fantastic artwork. Beta 026 is being tested at the moment and we should expect a public BETA release very very soon.

The E17 CE is maintained by Maty from Costa-Rica and its artwork is being developed by Molom from Australia. This edition uses the Enlightenment desktop. Although no beta has been tested yet the E17 team has communicated a lot about the project and recently set up a blog which was added to the Linux Mint planet. According to the blog we should expect this edition to become stable this month.