triaging and marking dups - a warning and advice

[Wayne Schuller <k_wayne linuxpower org>]

hi everyone,

Please be careful when marking duplicates everyone.

Some people have been putting duplicates in 69333 that belong in more
specific bug reports, like 59500 or 51417.

69333 is really a place to catch dups from the RH 7.2 crash without any
backtraces.

Those that do have backtraces should be grouped together in a different
dup list. that is what we have done with 59500 and 51417.

In fact a couple of good jobs for aspiring bug-hunters would be:

1. Go through all the dups in 69333 and move the relevant ones to the
more specific bug reports.

2. Look for patterns in the stack traces of the 69333 dup list and
create some more specific tracker bug for each stack trace, and move the
dups to the proper report.
When you do this, remember to put the crashing function in sqaure
brackets in the report description where all the dups are marked. (and
probably post to this list telling us where you are marking the dups, so
we don't do it in 2 different places)

Leave the generic, no stack trace reports in 69333.

Using the bugzilla reports is a good place to find the dup lists.
eg:
http://bugzilla.gnome.org/product-mostfrequent.cgi?product=gnome-core

Overall, the clean up of gnome bugzilla is going well, especially in
gnome-core.

Remember the goal is to organise the report data such a way that the
developers can easily see what is causing problems and fix them. So
although it seems like useless work marking duplicates carefully, it is
actually really important for a project as large as Gnome.

thanks,
wayne