[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
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
> 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
> 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
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
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
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
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