Distributed bugs

Posted May 14, 2008 19:35 UTC (Wed) by tialaramex (subscriber, #21167)
In reply to: Distributed bug tracking by tzafrir
Parent article: Distributed bug tracking

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.

(Log in to post comments)

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 (guest, #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.