Guillaume Cottenceau wrote:

There are two kinds of bugs: hardware and software. People who can't install mostly experience hardware problems, and for this kind of problems we have little influence for fixing..

So when, for example, I have problems on install with my Radeon 7500 (as in 9.0), is that a hardware or software bug? There are a large number of problems at installation that could be described as hardware bugs (problems with PDC and HPT controllers are other examples), but as other distros have found ways of dealing with the idiosyncracies of the hardware, should you count them as hardware or software bugs? I would have thought that the only bugs that are exclusively hardware are ones where all distros (and Windows) suffer from similar problems. Otherwise it is a question of how the software supports the hardware. Of course, you may not have access to the information you need to make the hardware work (although looking at other distros that have figured it out would be a good start), but that doesn't stop the problem being, at least partially, a software problem.


Funny :). A guy who resign using a stable release only because
the beta release contained bugs :).

I agree that this is not ideal, but as every system I had was screwed up in some way by 9.0 (and the final release screwed up worse than the RCs and betas), I can understand why someone would look at another potentially bug-ridden release and decide not to touch it for a while. Personally, I'll probably take the gamble (after all, how much worse can it be than 9.0?), but I can understand why others wouldn't.


We *cannot* detect PS/2 wheel mice.

I have the Belkin KVM + wheelmouse problem. The simple workaround is to Ctrl-Alt-F1 to a console and then Alt-F7 back to X, after which the wheelmouse works again. I can't remember where I saw it, but I read about a program someone had written to mimic the effect this had, which you could launch from a keyboard shortcut to correct the problem. It would be a nice little add-in for Mandrake to help with this problem.


Let it clear: we all want the most bug-free release possible.
Though, there are several parameters in the equation:

- by ourselves, we can't extensively test the distribution;
  hence, we need external testers: mostly people from cooker, and
  non-cooker people who test betas/rcs; this has limits because
  of mirror courtesy, mirroring time, and testers' motivation

Exactly. And you need not just a couple of dozen active Cooker testers, but 100s or 1000s of less active and more ignorant testers. Which means allowing plenty of time for bug-testing, because most of your users will not remotely have time to keep up with the pace being set.


- we have little chance to fix hardware problems ourselves

So you need as many people as possible to beta-test the release, to catch as many hardware combinations as possible. And then you will need plenty of tolerance and patience with the bug-reports that will come in with incomplete, inconcise information, because if you want to spread your net widely, you will have to expect that many people testing the system will not be experts.


- when you go down fixing smaller and smaller software bugs:

- developers's motivation decreases

I have every sympathy with the difficult position that Mandrake developers are in, but I have no sympathy with an attitude that dealing with the details is somehow beneath developers paid to do exactly that. The devil is in the details. If developers don't have the motivation to fix small problems, they are in the wrong job.


   - you increase the probability to break larger things (because
     many things interact w/ each other), thus you still need to
     test "all", and testing "all" needs time and motivation
     (both internal and external)

Don't fix small bugs because you might break something bigger??? Try repeating that to yourself a few times and then ask yourself if that really sound like a strong argument.


- the distro becomes more and more outdated

It has always been a big part of Mandrake's appeal that it is "cutting edge", so I think this is your strongest argument for as short a testing period as possible. However, if you go back to the 7.x releases, Mandrake managed to combine being "cutting edge" with stability and the widest hardware support. Things have been going downhill since then, presumably partly due to the diversion of resources during the old management's interregnum. But it seems to me that there was also a change of philosophy after 7.x, where stability and wide hardware support were given steadily less and less prominence. The supermount saga of the 8.x releases was a warning (it should never have been enabled by default until it had been tested thoroughly), and 9.0 was the culmination of this philosophy - advanced but bug-ridden. 9.1 and 9.2 need to take a step back in the other direction by ironing out as many wrinkles as possible, not carry headlong on with the pursuit of features at the expense of useworthiness.


- not all bugs are important; people who experience bugs worry
  about it but sometimes they are nearly the only ones having it,
  and they not all deserve delaying a release

How do you know if they are important or not? All you know is that there is a problem with your software. You don't know how many people it will effect, or how important it will be to those it does effect. Just because you don't think it's important, doesn't mean that your customers will agree with you. Any bug could be the one that annoys a reviewer and gets you a bad name. If you have pride in your product, you should believe that all bugs are important. That doesn't stop you prioritising the fixes, and accepting reluctantly that some will make it through to release, but that would be a very different attitude to assuming that some people's problems are not significant.


- we provide updates

True, but this doesn't help if you experience bugs during or immediately after installation that get in the way of applying the updates (e.g. network, UI and draktool problems). Many of the bugs being reported affect the functionality of the system on first use, so inexperienced users may well find themselves in the "Catch 22" situation of needing to apply updates to make their system usable, but not being able to apply the updates because of the problems with their system. And even if you manage to apply the updates, this will not dispell the bad impression that is given by the original system being broken. How many of us would regard as a feature Microsoft's requirement of users to download and apply Service Packs to fix their broken OS?


I accept that not every bug will be fixed before release. But that is not the same thing as saying it does not matter. Every bug matters, and in Mandrake's current position, eliminating as many as possible before release is more important than ever.

It all comes back to how much time you have. If Mandrakesoft have to have releases every 6 months (which I personally think is too frequent to be practical) and are under financial pressure not to delay, wouldn't it be sensible to go beta shortly after the previous version was released?

Cheers,

Bruno Prior




Reply via email to