Distributed bug tracking [LWN.net]

Distributed bug tracking

Posted May 14, 2008 19:04 UTC (Wed) by tzafrir (subscriber, #11501)
In reply to: Distributed bug tracking by mh
Parent article: Distributed bug tracking

The Debian BTS also tracks the status of a bug in different branches.

Here is a bug that is currently open (marked as red) on two different branches:

http://bugs.debian.org/456780

This can be done in retrospect. I can mark a version (= tag) as buggy well after 
releasing it. Though there's a useful shortcut for closing a bug in a changelog of a new 
release, which is mostly an equivalent of a commit log .

There is a different use case that has not been mentioned so far:

What about this bug upstream? What about this bug in Gentoo?

(Log in to post comments)

Distributed bug tracking

Posted May 14, 2008 19:20 UTC (Wed) by iabervon (subscriber, #722) [Link]

One thing I'd really like to be able to do is report that using xscreensaver crashes my X
server. Does this go to Ubuntu? X? xscreensaver? ATI? DRM? Mesa? The really right thing would
be to encourage all of the above to discuss it amongst themselves, because the actual answer
may well be that it's an incompatibility between particular versions of two different
projects, and the solution is for Ubuntu to apply a patch known to one of those projects to
the version they're shipping or use a newer version of the project.

(IIRC, it turned out to be that OpenGL had issues with the vesa driver and the particular
graphics card; telling xscreensaver to just blank the screen worked, and switching to the
proprietary driver to get dual-head fixed it as a side effect)

Distributed bugs

Posted May 14, 2008 19:35 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

Yes, that's actually a much more interesting problem for Free Software (well, it'd be
fascinating outside of Free Software but the issues quickly turn into a quagmire that would
drown any attempt to solve it)

Wouldn't it be great if a user could create a bug "Why doesn't my foozle work with banjo
properly?" and after a while having exhausted their own ideas they could send it to Fedora, a
Fedora developer could look at it, and after discussion with other Fedora developers, send it
to the Foozle developers, who would take one look and say "Aha, that's a Banjo problem" and
copy it over to the Banjo guys, who might say "Yeah, we fixed that in Banjo 1.4.3" and
everyone involved would see all this happening so that then the Fedora developer can add
"Banjo 1.4.3 is in testing, and you should be able to update to it in a few days", set a
key-value field and later a Fedora automated script could add "Banjo-1.4.3.rpm is now
available, it may fix your problem. Please tell us if it does.

The key thought would be that this is /one bug/ not a series of different bugs in possibly
different bug tracking systems, which are merely related. It's one guy's bug about his Foozle
not working as he expected, and it simply connects into all these different bug tracking
systems. The same theory as Git would apply, disk space is cheap, so every system can have
visibility of the bug report in full, with every previous action and they just share updates.

Other ideas while I'm scribbling: Priority fields don't belong to the bug. This isn't a P1
bug, or a low-priority bug, it's just a bug, and individuals would have their own perspective
on its priority that was independent of and needn't even be sent around with, the bug report.
Severity may or may not need to be treated the same way.

Now that's something worth building. I wonder how hard it would be to get a working prototype
and then to sell existing projects on supporting this way of working.

Distributed bugs

Posted May 15, 2008 12:59 UTC (Thu) by emk (subscriber, #1128) [Link]

Hmm. This is an excellent and interesting idea. We frequently need to shift bug reports
between projects at work: "Oops! That's not our bug. That's really a bug in $OTHER_LIBRARY."

Working out the semantics may be challenging, though. In particular, the original project
needs to keep some sort of "tracking bug" (probably just the same bug), and remember where to
pull updates from.

You'd also want tags--not in a git sense, but in del.icio.us sense ("release-1.2",
"subsystem-foo", "mystery-crasher"). And those might need to be project- or
maintainer-specific under certain circumstances.

And would there be new "resolution" values? "Waiting for upstream to fix", for example?

Distributed bugs

Posted May 17, 2008 18:47 UTC (Sat) by vonbrand (subscriber, #4458) [Link]

The technical problems to be solved are (comparatively) trivial (even a single bugzilla keeping track of all bugs would be enough to solve half of it or so), the hairy, so far unsolved problems are the organizational (people) problems.