[ubuntu-x] Tagging Xorg bugs (especially -intel)

[Bryce Harrington]

On Tue, Apr 07, 2009 at 12:18:03AM -0400, Geir Ove Myhr wrote:
> We both agree that tagging a bug with the ubuntu version(s) where the
> bug exist is useful. Others may think this is a bad idea.

It can't hurt, and in fact it could provide information that may be of
use for e.g. tracking down when the bug first appeared.

I generally consider non-targeted bugs that are open as existing in the
current development version until proven otherwise.  If a bug only
affects, say, Hardy, I'll close the bug and sometimes open a task
against hardy if it seems warranted (e.g. if the reporter clearly wishes
to see the bug fixed in the LTS.)

> We also both think it makes sense to add the tags "intel" and "xorg"
> to all the bug reports. Within the scope of this package this is
> redundant, but many bugs originally reported for -intel may end up
> being in mesa, the kernel, xorg-server, etc. and the tags would then
> indicate that the bug affects intel chipsets and that it causes
> problem in xorg. Besides, people often add these tags anyway. Current
> status: intel: 133/267, xorg: 120/267.

I don't have a strong feeling either way on this.

> The point where we diverge is for tags identifying the hardware on
> which the bug is reported. Carey has been using the graphics core
> (gma900, gma950, gma3000, gma3100, gmaX3000, gmaX3100, gmaX3500, and
> gmaX4500, currently 18 bugs tagged), while I have been using the short
> name from http://intellinuxgraphics.org/documentation.html , which is
> what is reported as the chipset in Xorg.0.log (845g, 855gm, 865g,
> 915gm, 915g, 945gm, 945g, 946gz, 965q, 965g, 965gm, g33, q33, g35,
> q35, gm45, q45, and g45, 110/267 open bugs). Of course, we both favour
> our own scheme ;-)

Mapping based on the graphics core may be more accurate, but I'm not
certain.  I would find the latter scheme more comfortable, since I'm
more familiar with the chipset short names.  However, I prefer putting
the short names in the bug title (upstream requires it anyway, plus it
makes it a bit easier visually when reviewing reports, and it can help
cut down on me-too-ism), so maybe that is redundant with tagging.

> Finally, a set of tags for tossing bugs with similar problems in the
> same bin: crash, corruption, ghost-monitor, dual-head, edid, 3d,
> video, compiz, resolution, suspend, hibernate, resume, hang,
> performance are currently applied tags that come to my mind.

I really like this idea; it could very much help in tracking down
dupes.  Also, when fixing bugs I like to look at other bugs that share
the same symptom since often I can use the same approach to fix them as
well.  A few comments -

'video' is a bit ambiguous, as it could me "graphics" in general, or
"video playback ala Xv", or "SVideo output".  I'd suggest using more
specific tag names here.

suspend, hibernate, resume tend to all basically mean the same thing.  I
would lump them together personally.

hang / freeze / lockup are all typically used as synonyms.  I think I'd
prefer 'freeze' over hang.  "lockup" would imply a GPU lockup - which is
a common bug but not all freezes are the GPU.

For additional ideas on tags, maybe see the Troubleshooting X wiki.

> If this makes sense to the rest of you, I can write a wiki page with
> currently used Xorg tags.

I like it.  I would suggest for sake of consistency, that we make sure
there is good correspondance with the Troubleshooting pages.  So if a
bug is tagged 'foobar', we should have a troubleshooting guide for
'foobar' issues.

> For other drivers, the hardware tags would
> be different of course. I guess for -ati one could use r100, r200,
> r300, r400, r500, r600, r700 and rs690 (taken from
> http://wiki.x.org/wiki/RadeonProgram).
> 
> Any thoughts on this, especially the core vs. chipset question?

As with Intel, I've also been putting the chipset name into the title,
and this has already had good results (I spent about a month on -ati
bugs and sorted a ton out via chipset correlation).

> PS: As of last week it was easy to get an overview of all the used
> tags, since they would all be shown on
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs
> . Now that only the most popular unofficial tags are shown, I don't
> know how to list all tags used for a package, so I may have missed
> some "active" tags in the above lists.

Wouldn't be too hard to write a launchpadlib script to list these out.

Attached is a script I wrote that does sort of the reverse - given a tag
and one or more source packages, list the bugs with that tag.  Output
looks like this:

$ ./ls-tag.py hang xserver-xorg-video-intel
Atttempting to reuse existing credentials
== Bugs tagged 'hang' ==
=== xserver-xorg-video-intel ===
320821  Incomplete [i945GM] After loading background crashes back  to GDM. Works with 'driver "vesa"'.
312776  Incomplete [965GM] Intrepid RuneScape Fullscreen 3D Java Applet Crashes X
321491  Confirmed [i915gm] Intrepid: Error in I830WaitLpRing
322613  Incomplete [945gme] Intrepid Xorg crashed coming out of screensaver - log shows "[mi] EQ overflowing. The server is probably stuck in an infinite loop."
328918  Incomplete [i945] underrun on pipe A! prevents Xorg from starting.
331596  Incomplete [i965] intel GM965/GL960 causes system hang when triple buffer  On after resume
337243  Confirmed [gma3100] X.org crash on Intel 82G33/G31 (with stacktrace)
339982  Confirmed [GMA950] X hangs for no apparent reason
340652  Incomplete [Intel] Jaunty desktop liveCD freezes on Intel iMacs on boot
340964  Confirmed [i915] Brightness change crashes X
10  total bugs tagged 'hang'

Bryce
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ls-tag.py
Type: text/x-python
Size: 797 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-x/attachments/20090406/5f73828c/attachment.py 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arsenal_lib.py
Type: text/x-python
Size: 11462 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-x/attachments/20090406/5f73828c/attachment-0001.py