Quoting Joey Hess ([EMAIL PROTECTED]): > 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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
