This reminded me of another tag, the d-i tag. This tag has always been problimatic since we don't always tag bugs on d-i components with the d-i tag (and doing so is busywork), but without it it seems hard to get an overview of all the bugs affecting d-i. I think a good compromise is to use the d-i tag only for bugs that affect packages that are not maintained by debian-boot@lists.debian.org. Then to see all the bugs you have to look at two separate pages: Bugs in our packages: http://bugs.debian.org/debian-boot@lists.debian.org Bugs in third party packages: http://bugs.debian.org/tag:d-i One problem with this is that bugs can overlap and show up in both if it's tagged d-i and filed on one of our packages. I've removed the d-i tag from such bugs. (Seemed better than excluding d-i tagged bugs from the first list.) So, don't tag a bug d-i if it's maintained by us, but do add the d-i tag when reassigning to a third-party package. Another problem is that installation reports show up in the list of bugs in our packages, so it is hard to get a feel for the number of isolated bugs. Is there any way to avoid this? Anyway, we have a lot of open bugs and I think it would be nice to have some kind of coordinated bug (and installation report) triage event after the beta release. -- see shy jo
Attachment:
signature.asc
Description: Digital signature