Re: a forth release?

[Helmut Wollmersdorfer <helmut.wollmersdorfer@gmx.at>]

Frank Küster schrieb:

> Speaking for my packages: Not good enough. With about half of the bugs
> in tetex-*, it takes a couple of days (or weeks) until we have sorted
> out whether it's a local misconfiguration (you don't imagine what people
> do...), a user error in the usage of TeX packages, or a real bug. 

ACK.

> Only
> then (and if it's a real bug) can we check the versions it applies to,
> and tag the bug accordingly.

Maybe the "bug administration" should be improved. A bug report without 
exact description of
- version
- misbehaviour
- awaited result
is useless in nearly all cases.
In commercial projects I - in my role as (senior-)tester - would never 
accept an unclear report. It is a good practice, that somebody "skilled" 
checks "submitted" reports if
- description is sufficient
- reproducable
- bug or not
- wish, change request or not
Result of the check is severity, decision bug versus wish, and switched 
state to "released" (or closed, duplicated, request for additional 
information). Only released bugs are real bugs.

> Usually this won't happen until the next bug report drops in, also
> unclear, and also with unsufficient info to tag it with a version.

See above - it is not bug.

> By the way, one wouldn't want wishlist bugs to prevent a package going
> into "candidate", 

ACK.

> But then, many bugs come in with inadequate severities.

The severity of incoming reports can always be to low or to high.

> I really don't think "bug reports in the last n months" is
> an adequate criterion for the quality of a package.

ACK.
But what should the criterion be?
It should depend on severities, which needs clear definition of the 
severities. And it needs a rule, how many known bugs of which severity 
are allowed to let a package into stable, e.g. highest severity = 0, 
medium = a few, minor = don't count.

> And this doesn't solve the problem that you would need to artificially
> keep new uploads out of testing. 

But that's exactly, why something ("RC") between "testing" and "stable" 
would be nice. Precondition is, that packages in "unstable" should stand 
a sanity check, before they go to "testing". And yes, this does not 
solve the problem, that you can dedect a release critical bug in testing 
and have the same bug in all newer versions. Even in the stable version 
a bug of highest severity can be dedected - what with this?

Helmut Wollmersdorfer