On Wed, Oct 03, 2007 at 07:27:15AM +0000, Josselin Mouette wrote:
> Le mardi 02 octobre 2007 à 18:01 -0500, John Goerzen a écrit :
> > No, that is a lot of manual work.
> >
> > I mean something like:
> >
> > $ bug-forward 456789 bacula
> >
> > and have it Just Work.
>
> When forwarding a bug report, the longest task is not opening the bug
> itself, which is just a copy&paste; the trouble is about finding a
> duplicate bug upstream.
I honestly reckon that I've many times not done this search
thoroughly, and I agree. And I disagree with John about 15 minutes. When
I was triaging the KDE bug tracker, here is how I worked:
step 1: take the bug, try to reproduce it.
- if able to reproduce it: open my browser, log (automatically because
my browser remember my password for me doh!) in, report the bug (and
for small upstream packages try to make sure that the bug isn't
duplicated).
- if not reproducible, many cases:
* either it looked hard to reproduce, and then I asked the
submitter about wether he still experiences the bug or not ;
* either it looksed trivial to reproduce and is not anymore:
depending on the age of the bug (e.g. if it was a KDE2 bug …)
then I close it, else I tag it unreproducible, in a mail sent to
the submitter asking if I took the right decision.
Of course, unreproducible bugs without news from the submitter
for a long time gets closed after a too long idling time.
It took me between 5 to 15 minutes per bug. And the longest part was
the "trying to reproduce" one. Forwarding upstream is rather a 5 minutes
operation, especially if you do many bugs in a row. And linking the
debian and upstream bug is half a second:
$ bts forwarded nnnnn <upstream-url>
nnnnnn and <upstream-url> being both in your clipboard. Then I can
lazily rely on bts-link to wake me up when upstream bug report changes.
So unlike John, I _do_ believe this approach scales well. Or at least
not so badly, because it's an almost O(1) operation per bug. OTOH, I
also do believe that the pinging mechanism I described many times
already could help preventing forwarding some bugs for bugs that are
long gone, but that the maintainer didn't had the chance to test in the
first place because he was busy with any of the other 1000 he has to
deal with, and preventing him to "lose" this O(1) time at all. So I'm
really in favor of something in debbugs doing that (as it's easier from
the BTS side, but it's 100% doable externally of course).
This mail make me also think that forwarded bugs do not need to be
pinged (or on a very less regular basis) as some upstream already apply
pings, and that we don't want our pings to compete with upstream's.
So right now the proper criteria for me looks like that:
every trimester (?) compute the list of bugs that:
* are applicable to current unstable (to avoid pinging for bugs in
stable ;p)
* are not yet marked as found in a current upstream (meaning that we
would _not_ take the package debian revision for that, if the bug is
marked as found in a 2.3-4 version, then if the current package is
2.3-12 we don't ping)
* have seen no activity for more than 6 months
* is not tagged wontfix, nor "forwarded"
a mail would be sent to the nnnn-submitter@ asking for the submitter to
send a mail to control@bugs.debian.org with the correct action (mark the
bug as found, or close it). Thanks to the soap interface to the BTS, we
could even make those URL's the submitter would only have to click
onto[0] (with some mechanism to avoid bots closing our bugs ;p). I
_really_ think that this isn't very intrusive, and could help many
maintainers in Debian focus on bugs that are still here.
[0] we could even make a nice per-submitter form where the user could
mark bugs that are fixed as such, mark the ones that are still
here as found, and leave the ones he can't test anymore alone in a
nice form, so that it's even simpler.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgp8Yw9WRshnn.pgp
Description: PGP signature