| |||||||||||
Distributed bug trackingDistributed bug trackingPosted May 14, 2008 18:40 UTC (Wed) by mh (subscriber, #7058)Parent article: Distributed bug tracking
Most email based bug trackers, such as the Debian BTS could be considered distributed in as much as they allow you to use them while "strapped into a seat in a tin can"
(Log in to post comments)
Distributed bug tracking Posted May 14, 2008 18:45 UTC (Wed) by joey (subscriber, #328) [Link] Well, not so much. You can open new bugs and reply to existing bugs, and close bugs from the plane, but you cannot *see* bugs, unless you've performed an expensive caching operation before getting on the plane. And yeah, been there, wanted to do that, and had to settle for watching in-flight movies instead. But, I don't think that use on a plane is really the intereting use case for distributed revision control, or BTS.
Distributed bug tracking Posted May 14, 2008 19:04 UTC (Wed) by tzafrir (subscriber, #11501) [Link] 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?
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.
Distributed bug tracking Posted May 15, 2008 13:39 UTC (Thu) by Jel (guest, #22988) [Link] What you're talking about is remote access and possibly offline preparation of bug reports. When people say distributed in terms of version control, they're talking about a system that has no central repository; just lots of peers, like a p2p system. In particular, they're talking about a system where each peer can be a completely self-sufficient branch, looking after it's own new features, bugs, etc., until it's all accepted into another (so-called upstream) branch and merged.
Distributed bug tracking Posted May 23, 2008 1:53 UTC (Fri) by kevinbsmith (subscriber, #4778) [Link] There seem to be (at least) two distinct clumps of benefits that might come from distributed bug tracking: Offline work, and...something about p2p, no central authority, etc. I completely understand the first, and it was the focus of the first few paragraphs of the article. The second is much fuzzier for me. I have been a proponent of DVCS for years, largely for that second reason. It can make projects more democratic, avoiding bad gatekeeping. But it's not clear to me that bug tracking has the same set of issues. It's pretty rare to be denied write rights to a bug database for an open project. It's also hard for me to imagine cases where I would really want to create a personal branch of bugs. The other aspect that has been mixed into this conversation really has little to do with whether a bug tracker is distributed or not: Integration. The ability to attach a commit to an issue resolution is powerful in many ways...but could be done with CVS and any centralized bug tracker. Finally, at least for now, I am definitely in the camp of not wanting bug reports to be stored inside each code branch. The bug database definitely feels like something separate, to me.
|
|
||||||||||