Hi Launchpadders!
For the past few days I've been helping Fabio with triaging xorg bugs.
Except for filing and commenting on a few odd bugs in the past, this is
my first real view of Malone, and esp. on the receiving end. After
working with it a bit, I have two suggestions for improvements. I wasn't
sure if this should be written up in the wiki, here or filed in LP, so I
opted to start here.
These two suggestions have the one thing in common that they are meant
to help the original submitter to 'do the right thing' from the
beginning, thus improving the quality of the bug reports and making life
easier for the maintainer and community triage volunteers.
== Package-specific guidelines ==
Taking the xorg package as an example there are certain things that are
nearly always useful when submitting bugs against it, namely getting the
xorg.conf file, the xorg.0.log file in case of crashes, and often the
output from lspci and ddcprobe. Digging into the bug could start
straight away if this info was supplied with the first bug report,
reducing the need for any real triaging. We have just recently started
using a simple script written by Seveas to simplify this process. We
just instruct the reporter to run these two commands:
wget http://www.ubuntulinux.nl/files/pastebin
python pastebin --debug-x
And the output appears like this: http://paste.ubuntu-nl.org/11955
So, getting to the point: For many packages it would be good to be able
to provide some custom advice on how to report a bug against it. For
xorg that would also include 'If your screen looks garbled, it's likely
a driver problem and should e filed against the appropriate package:
xorg-diver-<name>, if it's a keyboard config problem, please file
against xkeyboard-config, etc.
I would suggest implementing it as an expanding section on the bug
reporting page. 'Click here for guidance on reporting bugs against xorg.'
== Fuzzy duplicate matching ==
Another major task in triaging is finding duplicates. The person who
makes the initial report may often be in a good position to spot a
duplicate because he/she knows the situation or hardware in question
well and might have a better chance at recognising a similar report than
some random person (me in this case) helping out with bug triage.
However, the original submitter may not know Malone well enough to do an
effective search for it or not be motivated enough to do one. One
possible solution is to have the person report the bug and then have
Malone do a fuzzy search for similar content on bugs reported on the
same package. This could be a general word comparison, but each package
could also have certain key words defined for it that would weight in
strongly in finding matches. For xorg this would be 'wxga', 'i915',
'nvidia', 'crash', 'gdm' etc.
Upon submitting the bug the reporter would be given some suggestions for
possible duplicates and asked to look them over. 'It is possible that
some of these existing bug reports already describe the situation you
are reporting. Please read and help us identify possible duplicates.'
Possible duplicates could be tagged by the original reporter and later
reviewed by a triager or maintainer.
- Henrik
--
http://www.ubuntu.com
http://www.theopencd.org
--
launchpad-users mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/launchpad-users
