On Thursday 06 March 2003 19:08, George Mitchell wrote: > Andi, there is a solution to this problem. That is to maintain a stable > version of cooker. Do the actual work of upgrading and fixing various > components offline, and merge them into the stable cooker tree only when > they have been thoroughly tested. In the mean time continually use > bugzilla to QA the stable cooker tree itself. As it is, cooker is a > collection of a gazillion efforts all attempting to take place > simultaneously on the same codebase, and all attempting (or forced) to > come to maturity at the same time. And even though the software is > modular, there are cases where a problem with one component can > jeoperdize a timely fix for another. The various efforts need to be > delinked and individually debugged on a stable cooker. The existance of > a stable thoroughly QA'd cooker would mean that Mandrake could pull the > cord for a release at any time without risk of unforseen headaches.
Cooker the way it works today--a not-quite-stable, not-quite-integrated repository of version upgrades and new packages that may get into a future version of Mandrake--is one of the major advantages of Mandrake over the other linux distros. I wouldn't want it eliminated. I like the fact that I can usually get a Mandrakized package of the latest version of XXX quickly after it's released, and usually it works--even though occasionally there are problems. The fact that I can't get that with any other distro is a big part of the reason that I use Mandrake. And no development project can stay in "release mode" all the time, without separate branches for blue-sky/experimental/unstable work. So really, you'd need to split Mandrake development into three branches instead of two: 9.1 upgrades, a mostly-stable "pre-9.2" Cooker, and a like-today's-Cooker "experimental" branch, with solid QA on both of the first two branches. In fact, the first two could share much of the same team: close to a release, both would be working primarily on getting 9.2 ready to go out the door, while shortly after a release, both would be working on figuring out what can be hammered into 9.2 as an update and what has to wait for the future. And this does in fact work for some other projects (including Debian, I believe). But still, it would require more Mandrake resources, and more user involvement, than the current system. And, while you would probably attract new people to the Cooker effort if it were a more stable system, you'd also find that many of the people who help today would prefer to work on the blue-sky branch. A compromise might be to do a QA'd sub-release of Cooker every two months, rather than every six months. A single team can work on a project with release dates this short, spending a couple of weeks in freeze every two months. I think most Cooker users would put up with these freezes in exchange for an even-more-usable Cooker. And, more importantly, both Mandrake's team and the user community would have more experience getting together a solid release; it would require less work to tie together two months' worth of development than six; and there'd be a solid way to back-track any subset of the distro, if necessary, without going all the way back to the last major release. But I'm not sure the system really needs to change. Is it really working that badly? The consensus on this list seems to be that there are major problems with the releases. And, to be honest, people I know who've been using Mandrake for a long time complain that each release is worse than the last. But people I know who've switched from other linux distros, or from Windows, have mostly been happy with the stability of Mandrake 9.0. (True, people who came from MacOS or BSD had lots of complaints, but you can't make those people happy....)
