[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

d-i tag (was Re: Using usertags to process installation reports)

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

Reply to: