-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Dorman wrote: > Timothy R. Butler wrote:
> [Rant on] > > Whilst I am confident that the Mandrake developers can get this version > pretty polished by the current release date, I do think that Tim has an > important point with regards to calling these things "release > candidates". Clearly the current .iso's aren't release candidates, they > are betas. Calling them release candidates seems to be a convenient way > of getting more people to try out the distro and thus report bugs. Note here that you are saying people shouldn't be testing betas ... but The > logic is sound (people avoid the betas, and flock to the rc's), but the > message is very flawed. Reviewers report on release candidates. People > get pissed off when they download almost 2 gigs of distro they can't use. > > I would like to propose two alternative approaches for future releases: > > 1. Tweak the beta program > > Keep the beta program running until there are basically no bug reports, ... WHERE DO THE BUG REPORTS COME FROM IF NO-ONE TESTS THE BETAS? There were very few bugs before rc1 was released. > then shift to rcs, where only tweaks can be made (graphics, rcX -> > release package updates, etc.). Maybe you haven't been following, but after rc1, no package upgrades can be done in main without release manager approval (ie security fix). > When the release candidate comes out, > people should be able to test it on production machines (in the case of > workstations), and on sandboxed servers. Why? Because they are /release > candidates/ and not betas. > Many people run cooker on production machines. rc1 is find on my laptop (after one or two tweaks). > ***REWARD*** beta bug busters and reporters. With what? Why? Many of them get the distro for free, and fixing their bugs is in their own interest. And if bug reporters get rewards, what do the people who run cooker and maintain packages get? > > 2. What the hell is a distro anyhow? > > Why is it that companies like MandrakeSoft, RedHat, etc., are putting > all this effort into syncronising the release of 3000 or so software > packages at once?(????!) Why not split the distro? Make a bunch of > mini-distros which can be managed separately (Down to per-package level > if desired)? So that all the packages actually work. One could be for the installer framework, one could be base > libraries, one could be for the development stuff, one for servers, > etc., etc. (ooh, I'm feeling nostalgic for my old Slackware days!). Have > a management system which keeps the components for up to date over the > 'net according to each user's preference. One that can configure and > burn a custom set of iso's, ready to install like a regular distro > (great for OEMS, or people maintaining different machines). Tell the > system to prepare Joe-user's desktop distro and you get one CD, tell the > system you want Mel's-multimedia-mayhem and out pops another. Even add > processor-specific compiles to the mix! Each section would have it's own > users working towards optimum stability, features and performance. That does not help in sycning packages, since all the packages still need to build on the same compiler, same libraries. Waiting a month to release a subset of packages does not help anyone. > Surely something's got to change. Creating megalithic multi-CD distros > is archaic and is going to get harder and harder. Lindows (Click'n'run), > Ximian (RedCarpet), and others have worked it out, so why can't we? And > *we* can do it with strong community participation! > So, download network.img, and do a network install. Much more advanced than Lindows. Buchan - -- |--------------Another happy Mandrake Club member--------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+Z2KErJK6UGDSBKcRAnutAJ90wyou/2es0/qo475FQZj9CPkpLQCeMDEv 3BHUs4/OIaUqlmH1JSPoEPo= =6lji -----END PGP SIGNATURE-----
