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

Re: Google SoC - Bug Triaging and Forwarding Tool

On Wed, Mar 28, 2007, Anthony Towns wrote:
> reportbug-ng already does something like this. Have you looked at that
> program?

 FYI, I've already pointed at reportbug-ng in
 <[🔎] 20070320151820.GB23237@bee.dooz.org> and in the comments of the GSoC
 entry.  I also pointed at bts-link which has some BugZilla (BZ) logic,
 but Pierre commented that it was not worth using.

> > * Change the bug tags (generate and send a control mail with the
> >   choices made by the user)
> > * Search the upstream BTS for similar bugs [...]
> Philip Kern worked on this for last year's SoC, but I'm not sure if the
> code actually ended up working and I can't remember where it was now. :-/
> The best I can find is some mock-up screenshots at:
> http://lists.alioth.debian.org/pipermail/soc-coordination/2006-August/000058.html

 IMO, tag manipulation would not be the main goal of this program; I
 would mostly see it as a nice addition when using such a tool --
 instead of switching back and forth to the "bts" command and copying
 bug # around.  I think the real value is in the "Forwarding" part and
 how to automate it.

> Personally, I find triaging mostly involves grouping rather than followup
> -- ie, the process is look at all the bugs, group related ones together
> into a bloc (by what area of the code they impact, how important they
> are, whether there's anything that can be done about them yet, etc),
> and then choose a group and do detailed followup/resolution on those bugs.

 It's not really like this in the GNOME packages.  Sure, you can have
 duplicates, but most of the time it's a lot of different bugs, and even
 when they touch the same area, they get reported separately upstream
 because they are separate bugs after all.

> Would it make sense to focus on the tagging aspect (either with the
> standard tags or usertags) so that your program just makes it really
> easy to set tags so maintainers can get a good idea of the state of
> their package (and share that idea through the use of tags), and fire
> off reportbug or a web browser for following up or reading bug logs?

 I wouldn't find a GUI to set tags very interesting, even if usertags
 might not be very easy to set.  I think the big big value would be to
 automate the upstream matching and submission.  Some examples of things
 we could do:
 - search for bugs with the same long words in the bug title
 - search for a backtrace in the Debian bug matching an upstream comment
 - have an input field to manually research upstream bugs with some
   sensible defaults (the upstream web page does not allow saving
   default query settings AFAICT) and permit connecting them
 - one click bug forwarding which extracts the Debian bug report and
   wraps it in an upstream bug "Debian user $x reported in Debian bug
   http://... that ...", using the correct upstream module and setting
   the correct upstream version

 I'm sure you can imagine the time saving advantages when we need to go
 through hundreds of bugs across different packages and need to repeat
 searches, bug reports, and various settings in the queries and reports
 (such as Cc:ing the GNOME team for updates).

 Beside, there are other big upstream projects relying a lot on BZ such
 as KDE and Mozilla which would directly benefit from the tool.

Loïc Minier

Reply to: