Re: bug triage
Quoting Joey Hess (joeyh@debian.org):
> I'm unclear whether you're talking about dealing with all d-i bugs (most
> of them are tagged d-i), or with installation reports too. Having some
> people work on managing our bugs would indeed be quite useful. Some
> examples:
>
> - bugs against individual d-i components are not always tagged d-i,
> and so they don't show up in queries like "bts show tag:d-i" and are
> easy to miss
> - bug priorities are often wrong
> - bugs are reported against pseudo-packages "install" and
> "installation", or even "boot-floppies" and have to be reassigned to
> debian-installer where appropriate to be noticed
I would add some bug triage to individual packages:
-sorting bugs for partman-*
> Plus we have 500 or so uncategorised installation reports (on the
> installation-reports pseudo-package). There's a document[1] that
> explains how to categorise them, but it takes a lot of effort to learn
> enough about d-i to become good at this, and then the task soon becomes
> tedious, and few people have managed to do more than a hundred or so
> total. So I think a more accessible way to help with a lower barrier to
> entry is a find idea.
As a first work and provided everyone agrees, I think that closing all
reports pertaining to beta2 and beta3 with just a word pointing to
current daily builds would be good.
It is highly unlikely that these reports currently bring some new
input on nasty things in d-i as beta2 and beta3 are far to differnt
from current d-i (except maybe hardware support for this or
that....but what else other than "please try daily build images" could
be done ?)
If such work is done, it's however important to give very precise
instructions on which image is to be used....so giving an URL of a CD
images (most of the time these are tests with CD images anyway)
Reply to: