[Desktop_architects] Cross-site bug tracking

Aaron J. Seigo aseigo at kde.org
Tue Apr 10 10:43:54 PDT 2007


On Tuesday 10 April 2007, you wrote:
> > trying to bridge the various bug systems is a pragmatic approach and
> > starts to bridge the gap between various cross-stream sources, but falls
> > far short of addressing other very real issues that exist such as:
>
> Pragmatically, getting everyone in the open source world to switch bug
> trackers would be extremely difficult.  My guess is that it'd be like
> what happened with the community-wide CVS->SVN migration over the past
> few years; instead of everyone ending up on SVN, there came a
> proliferation of VCS systems and things have gotten more diverse, not
> less.  My bet is that any push to move projects from bugzilla to a
> better bug tracker is going to result in a similar proliferation.  For
> interoperability purposes, that could actually work counter to our goal.

a key difference might be that the only reason one would switch from their 
current bug tracker to a new one is for interop. which would make it seem 
like there would be a much better case for working on one system.

that said, the VCS diversity seems to be boiling down to just a few 
contenders: svn for centralized dev and git for decentralized. natural 
selection does work, if it takes its time in doing so.

and of course, we don't need everyone in the open source world to switch. just 
those who care ;)

> This is why I tend to feel that rather than making projects change bug
> trackers, it might be more productive to come up with a generic
> inter-tracker communication format for bug reports, and patch in support
> for that into all the major trackers.  Then no project is faced with
> having to change from what they're used to - they just gain a new
> feature on what they already have.

this is a fine mid-term goal, indeed.

it still wouldn't address numerous other issues with current bug tracking 
systems. i think it also trivializes the job of upgrading trackers in many 
cases; while i'm sure for some it's trivial, i know we in kde avoid doing it 
too often as it rarely turns out to be simple. it would be important to do 
the work on (or backport it to) the last stable release(s) of each tracker 
rather than just the next revision of the tracker as that would seriously 
hamper uptake.

that said, a data schema for interop defined would also solve migration to 
$NEW_TRACKER issues and make it much more plausible to move to something new 
and interesting.

> Bug trackers contain similar-ish data, so a universal bug schema ought
> not be that difficult to identify.  And interlinking and trackbacks and
> such sound blogging-ish; the wagon ruts are well worn there.

the schema is easy enough; the integration with each tracker and subsequent 
interop testing is what will be the time drain.

i would be content with interlinks and trackbacks, but actually being able to 
merge / branch bugs between repos (e.g. my local bugs, kde's upstream bugs 
and $DISTRO's downstream bug repo) would be just awesome. but yeah, applying 
some basic "web 2.0" techniques would be an improvement even.

> In theory, databases also allow network access to the data, although no

so do scm's, and they are actually meant to be open to the network in safe 
(enough?) manner.

> So yeah, I think the concept of "invent a bug report XML schema, throw
> them all in a webdav filesystem, add an inotify-based search tool, and a
> couple tools for adding/editing reports" would be a very interesting
> approach.

personally: s,webdav,git repository,

the reason why i lean in that direction is then each comment could simply be a 
revision on the bug report; we'd get off-line, branching and merging for 
free.

a particularly neat possibility would be to have bug branches in parallel or 
even mixed in with git source code repos. it would make integrating scm's 
with bug trackers, something every project does these days, soooo much more 
straightforward.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/desktop_architects/attachments/20070410/1a2765a2/attachment-0001.pgp


More information about the Desktop_architects mailing list