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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] OOO http://www.madism.org
pgpekkNNgjjFa.pgp
Description: PGP signature