New MDK release schedule

Note: I always refer to Mandrakelinux as MDK because we can't legally call it "Mandrake" and Mandrakelinux is a pain to type. So MDK it is. So we announced the new release schedule for MDK today. 10.2 to be renamed 2005 and made an interim release before the integration of some Conectiva stuff and the start of a new annual release cycle near the end of this year, with the release of a version named 2006. Overall, I think it's a good move, though we'll lose some things by sacrificing the six month release cycle. Six months is good for innovation and fast development, and it's good for PR. With a six month release cycle we're hardly out of the news for a month; you get a CE release, an OE release a month later, a Cooker snapshot a month or so after *that* and then we're into the beta cycle for the next CE release. As for development, six month cycles more or less force the developers to work fast; if you want something in MDK you'd better write it fast and get it into Cooker or it's going to be tough to get it working. However, the six month cycle has several big drawbacks. Number one is reliability. We really don't do this well enough at the moment. We have some releases that turn out to be excellent; 10.0 worked very well on just about any machine when it came out, 9.1 and 8.2 were other great releases like this. But there are also big mess-ups. 9.0 and 9.2 (with the LG CD-ROM drive issue, yes, even though it wasn't our fault) are examples of releases which had significant problems. Then there's the releases in the middle, like 10.1; they're overall excellent products, but with just enough little bugs and flaws to make things irritating (and cause unfortunate situations like the couple of hundred of MB of KDE updates to 10.1 which were available even before lots of people had the shipping product). This really is a product of the release cycle more than anything. A six month release cycle is ludicrously compressed. When an MDK release is done, the tree freezes for a couple of weeks for planning and also for a lot of the developers to go on holiday. Things don't really get going again for a month or so. Then there's a huge amount of *big* new stuff to merge in - for 10.1 we had new releases of KDE, GNOME, perl and several other huge MDK components to package and get working. By the time that's done, it's already less than five months until the next release. The beta cycle lasts at least a month - so there's less than four months to stabilise the new stuff, write updates to the MDK tools, make sure new hardware support is complete and all the other things that need to be done between releases. Then there's the beta cycle itself. On a six month release schedule it's really hard to make this last more than a month in earnest. This means the releases are ludicrously tight - we basically work on the basis of a beta or RC every week. One week Beta 1, next week Beta 2, next week RC1, next week RC2, next week stick a fork in CE, it's done. In addition, since there's an inevitable overlap between when the beta images are built and when they actually get out to users, each beta only actually gets about five days of real use before the next beta's images are frozen. And finally, a lot of people skip the betas and only start testing when RCs arrive. This whole schedule does not allow a lot of time, considering it's only really after Beta 1 comes out that the product gets widespread exposure beyond Cooker users and MDK's internal QA, and you really need this exposure to test things on a wide variety of hardware if you don't have the resources of Microsoft or Novell. Between each release, a lot of stuff is changed. For instance, take the kernel. From 10.1 to 10.2 we've gone through three kernel versions, from 2.6.8 to 2.6.11. Now we love the Linux kernel dearly but it is not the most stable (in the sense of 'unchanging') of beasts. Going through three revisions, something is going to change, and for some people, that means something is going to break. This means when we hit a beta cycle, we're going to get a miniature flood of hardware behaviour changes, regressions, or even improvements which need infrastructure (for instance, a new piece of hardware gets kernel support, which means we need to make the installer and the drak* tools detect and configure it properly). This means that there is an inevitable need to do a certain amount of moderately major surgery on very fundamental bits of the system - in a single month prior to release. This is not an optimal situation. So overall, the whole six month release cycle leads to some very...odd situations. For instance, we sent out 10.2RC1 for testing last week. This contains a rather silly kernel problem which means systems with some extremely popular soundcards - Creative Audigy and Soundblaster Live! models - hit a kernel oops during the startup process' ALSA initialization and freeze. This is really not something that ought to happen in a Release Candidate, properly named. However, the short release cycle, short beta cycle, moderate QA resources and the fact that most people aren't willing to run anything short of a Release Candidate all conspire against us here. Other things - if you follow MDK development closely, you'll know there's a fairly scary amount of heavy development work late in the beta process. For instance, during 10.2's beta process, the video configuration section of the installer and the control center has been heavily modified to allow much more flexibility in dealing with monitor resolutions; we can now handle non-4:3 resolutions cleanly and gracefully. This has actually been a remarkable success - all the code appears to work properly and has not broken anything that used to work (except for a few days during which it was not obvious how to select 1280x1024, as this resolution is not technically 4:3 so it was shunted onto the 'odd resolutions' list, even though it's a very popular resolution. It's now special-cased into the 'normal resolutions' list.) But it's still really a piece of engineering that _should_ be done outside of the beta cycle. There are lots of things like this, in MDK development. I definitely want to emphasise it's almost certainly not unique to MDK; I don't follow the development of the other major six-month-cycle distros, Fedora and Ubuntu, but I'd be amazed if they didn't have similar issues. The reported problems with the various Fedora releases (very similar to MDK problems - small, technically speaking, bugs that still really annoy users) in particular support this view. All in all, I've always been amazed at how *well* MDK's development eventually works. I've been following Cooker since long before MDK started writing me pay cheques a few months ago, and one frequently got the impression a couple of weeks before a release that it was going to be an out-and-out train wreck, which generally speaking didn't happen. Things get pulled together, an amazing amount of bugs *are* squished, and in the end we've always shipped a very good product which the majority of users are happy with and happy to pay good money for. However, there's definitely room for improvement. The other problem with the six month schedule is it just doesn't give much time to make major changes. If, for instance, we decided to completely rework the interface for the MDK tools, or change the package manager (both completely hypothetical examples, there's no current intention to do either) it would be very challenging to do on a six month schedule. There are potential fundamental changes and improvements to a Linux distro that a six month release cycle simply does not allow. In view of all this, then, I think a yearly release cycle is definitely a good idea. We will have a lot more time to do the fundamental work of updating software and revising distro tools. We will be able to introduce (hopefully, this is speculation on my part at this point) a longer, less hectic beta cycle with more time between releases and the potential to make our RCs really RC-grade. Overall, we'll be a lot more *sure* that what we're shipping is going to work the way we hope and intend it to. I'll kinda miss having something new to test and something new going out to people every day...but then, there's always Cooker. :) (please note - this is entirely my own personal impression. I wasn't party to the internal discussion on changing the release schedule, which is sensible as I'm not a hacker. I write stuff, language stuff. In most ways I'm as much an 'outsider' as most users. I did know about this a couple of weeks ago - I was busy proofreading the PR on Saturday! - but that's all. So don't take the reasons I gave for changing the cycle or the results that will come from it as official, it's just what I make of the whole thing.)