I'm sorry Buchan, but unless you snipped out the bit where I say people shouldn't test betas I can't see it in the paragraph you seem to be refering to.-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul Dorman 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
Aside from the point that I didn't suggest people shouldn't test betas, just where did all the new bugs come from? Very few bugs in the betas, but lots of bugs in the first release candidate? Surely people didn't feel sufficiently motivated to properly test the betas, choosing to wait until the rc's started coming out and then, because oh-my-goodness-/this/-is-supposed-to-be-a-release-candidate<!?!> people start flooding the list with their reports. And the reports are ...can't install...., ....won't run...., ......crashes......., ......doesn't properly support my [insert very common graphics card or other hardware device].... I'm sorry, but these sound like the kinds of issues you run into during the alpha or beta stage....
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.
The truth is, there were very few bug REPORTS before rc1 was released. The beta program needs more active and vocal testers. Many people are busy and might need a little incentive to get down and dirty with the betas, hence my suggestion of some kind of reward program. Use rewards to get people more active instead of coming out with 'release' candidates.
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).
I have been following, and I think this is fine, as long as release managers automatically allow packages which are themselves going from beta or rc to stable. Take for instance, oh, I don't know, the kernel. Should the release have another 2.4.21pre- kernel? Or should the maintainers let the final 2.4.21 release sneak in when it comes out? Is it good marketing to come out with a major release (and given all the hubub around MandrakeSoft's financial situation I'd say this is a major release) containing a prerelease kernel? Is it wise to be building a distro around a pre-release kernel when the deadline for the distro release is likely to fall before the release of the stable kernel version? And that's without going into *why* the kernel is still in prerelease....
Buchan, I've seen many of your posts on this list, and the vast majority of them are useful and sensible....
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).
So they don't get the distro for free. They pay for it with their time. How much do you charge for your time? And they are not 'their' bugs, they are bugs in the distro that have not been squashed...
***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.
Paid.
And if bug reporters get rewards, what do the people who run cooker and maintain packages get?
But they don't, do they?
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 baseThat is why it is a challenge to come up with an improved system.
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.
No it's not. First off, I'm not going to download every package I install into every separate machine. I'd rather download each package that I use just once, and then use different combinations of those packages when I'm installing on different machines.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.
When KDE3.1 came out, why is it that Mandrake-update doesn't by default make it an option? (that's for Joe-user, by the way, not the urpmi-elite) Why can't I produce Mandrake-9.0 isos with all the latest packages? Wouldn't that make sense? So I have to wait for the next release to get feature X or to get past bug Y? I have to download all the updates, and then the contrib-updates, write them to CD to install *after* I've installed all the stuff that I'm going to immediately update? Is this logical?
Don't get me wrong. I love Mandrake, it's a great distro, and I think the developers and cooker community are awsome. But doing the three iso image musical chairs thing is stupid. It's not an effective way of managing thousands of software projects. I think we need something that is more fluid.
Buchan
Ciao, Paul.
