Elyssa is a variant of Elissa and it is pronounced “eh-LIS-sah”. It is of Greek origin and its meaning is “from the blessed isles”. It was also the name of the 1st Queen and founder of the Phoenician city of Carthage, known by the Greek and the Romans as “Queen Dido”.

If you’ve been reading Husse’s newsletter you probably know it by now: Don (aka Exploder) is joining the team and replacing me as the person responsible for testing our ISO images before they get released.

The first advantage of this is that we’re going to achieve better quality and have less bugs slip through. Exploder is much better than I am at finding bugs and when he’s happy to see something released as I do the releases anyway I’ll run my own tests as well on top of it. So the BETA or STABLE ISO which ends on our mirrors will have been tested by the maintainer, by Exploder and by me 🙂 Of course there’ll always be bugs, don’t worry about that 🙂 But at least most of them will be caught prior to the release.

The second advantage of this is that it frees me up from something which required a lot of time. So I can now focus even more on the project, the main edition and the tools we develop.

As Ubuntu is getting ready for an LTS (Long Term Support) release in April, our next release will focus on long term stability rather than on the innovation of a lot of new tools. MintBackup is coming in but don’t expect the same level of innovation as in previous releases: Linux Mint 5 is going to be a boring release 🙂

What we want to achieve before this release is a better vision of how we work, how we define our editions, our tools, how we look at localization and in a very general way how we can improve not the Linux Mint desktop but the project itself and its organization. For instance, one aspect of the upcoming LTS Ubuntu base is that Mint 5 will get 3 years of security updates. This is an opportunity to create an enterprise desktop and a solution which can please companies. So we want to look into that of course. What would be the difference with the main edition? How would we go and conciliate development and updates between the new releases and the LTS one?

If we could manage to have this LTS release declined in two editions, one aimed at companies interested in stability, security, networking and another one similar to what we have now, aimed at individuals who want an elegant desktop. If we could manage to keep our 6 months release cycle, but at the same time still maintain these two LTS releases for another 3 years, and not only by providing Ubuntu updates but by also providing updates for important user tools (OpenOffice, Firefox, Thunderbird, Evolution, etc..). If we could manage to do that, we would be able to keep going on the way we are now but we would have a very interesting option for both companies and individuals. The goal here of course would be to accelerate the migration of companies to Linux and to place Linux Mint on the enterprise market. A 3 years release cycle for LTS is also very reassuring for individuals, especially if they come from Microsoft Windows and if we manage to upgrade user-level applications.

We’re also dropping minor revision numbers for our releases, so the next release won’t be Linux Mint 5.0, it will be Linux Mint 5. The codename hasn’t been decided yet.

If we look at our past releases we can see how the focus went from one area to another. After Bea was released we had a great Ubuntu base with our own tweaks and optimizations and with the necessary codecs and package selection. The focus changed from the system configuration to the development of tools in Bianca and that’s basically what we’ve been doing until the release of Daryna. Now that an LTS release is coming up and also because we’re happy with the quality of our current desktop we want to shift the focus and strengthen the project itself, make our tools more robust, revise our software selection, ensure a better level of localization, produce more documentation, work on our image and our offerings (not in terms of product as we’re not “selling” anything but in terms of what we can offer and to which audience), increase our efficiency in how we do things and let our community grow with us staying close to it.

So you see the list of planned changes for Linux Mint 5 has never been so small and at the same time we’re preparing for one of the most important releases we ever had. This time it won’t be only about the quality of our desktop but about how the project itself managed to grow with its community.

This is a very vague vision of course and as always your feedback is welcome. What we know so far about Linux Mint 5 is this:

  • It will be based on an LTS release (3 year security updates from Ubuntu)
  • We’re hoping to give it 3 years user-level application updates (OpenOffice, Thunderbird, Firefox, all important user-level apps), to maintain it, and while we’re developing other 6 months span releases to give it as much attention as the latest release gets.
  • Most tools will be translated in various languages and get minor improvements.
  • Amarok will be replaced with Rhythmbox (this might change).
  • mintBackup will be introduced.
  • We currently have a Main and a Light edition. It’s not decided yet how or if this will change but we’d like to introduce an enterprise desktop for this LTS, this might merge with Light into a DVD special edition with a radically different software selection.
  • A user-guide will come with the release and we’ll hopefully have that guide translated into many languages.

Right, enough said.. tell us what you think and how you see things happening.

Clem

PS: I didn’t realize I wrote so much.. sorry for the long blog post 🙂

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