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: