Re: QA and the freeze...
On Mon, 14 May 2001, Anthony Towns wrote:
> Hi guys,
> For the freeze to work well, there are two separate QA tasks that need
> to be done: (1) fixing RC bugs before the packages they apply to freeze,
> and (2) improving packages' policy compliance and overall consistency.
> I suspect it might be an idea for people to choose which of those tasks
> they're going to focus on and stick with it for extended periods.
> The first team will need to:
> * ensure packages port correctly
> * ensure they don't crash the system or delete files or whatever
> * have any known security problems fixed
> * make sure packages are usable
> * make sure they comply with all the really important policy guidelines
* file bug reports for broken dependencies as listed at
A suggestion for the severities of these bugs:
Depends -> grave or serious
Build-Depends -> serious
Recommends -> important (or serious/grave because dselect handles
Recommends like Depends?)
Suggests -> normal (but it might be a dependency on a package you have to
build yourself in which case it's not a bug)
> Some hints to make the RC bug fixing job a little easier:
> * There's no such thing as an unreproducible grave bug. Either it
> breaks for everyone, or it doesn't. If the program is usable for
> most people, it's not completely unusable.
That means when e.g. gcc gives "Internal compiler error" on ARM that's
not RC because it's no problem for most people???
I think you mix two things:
- Unreproducable bugs should be closed.
- You must decide whether a bug that hits only some people should be
Something like "if (arch == alpha) do 'rm -rf /* ' " is IMHO
RC even though it only affects < 5% of our users.
> * Serious bugs should be able to cite the "must" in policy that's
> broken. If they can't, it's probably not a serious bug.
And even when you can cite a "must" you can get flames that you mustn't
file bugs... :-(
Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.