[Desktop_architects] Cross-site bug tracking

Bryce Harrington bryce at linux-foundation.org
Tue Apr 10 11:36:21 PDT 2007


On Tue, Apr 10, 2007 at 11:43:54AM -0600, Aaron J. Seigo wrote:
> 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.

Nah, there's lots of reasons to switch...  better/different ui,
integration with svn/git, more powerful search capabilities, etc.

For Inkscape we use the SourceForge bug tracker, which is one of the
worst out there.  :-)  But selecting between the other various trackers
is quite hard - they all have significant advantages and disadvantages.

Also, while I agree with you that bug tracker interop is a killer
feature, I know a ton of developers who couldn't care less, and will be
much more interested in svn/git integration, wiki-style editing, and
other day-to-day features.  Language bias also enters into the picture -
some passionate about python, others php, perl, ruby, or whatever.

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

Well, keep in mind that there are already capabilities in bugzilla to
interop with other bugzillas, and other trackers have some limited
interop abilities, yet what we're talking about here is something much
larger.

Essentially this is a network-effect strategy.  The more people who
opt-in to using the interop bug tracking system, the more valuable it
becomes.  Time has shown that you do better here by standardizing the
protocol, and allowing diversity in implementations.  There are many
jabber clients, but they all (more or less) interoperate.  There are
many web browsers, but all read (more or less) the same html.  I see bug
tracking as a good fit for this model - allow many bug trackers, but
the same <fill in the blank> bug standard.
 
> 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.

True, and I've only dug into bugzilla, but looking at the various
trackers, it seems that in general either a) the tracker is not actively
developed, so backporting would not be a huge issue, or b) the tracker
is actively developed, and thus has knowledgeable developers who could
potentially help take care of the backporting.

So, as long as we're just handwaving things, I'd handwave this one too.  ;-)

Actually, a larger issue here is that in general hacking on bug trackers
is not in the "sexy project" category, so it could be hard to find
willing workers for it.  Thus why I think it'd be a good thing to find
funding for.

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

Yes, agreed.  Sort of like how SVG was intended for interop between
commercial drawing programs, yet ended up gaining traction as a format
in its own right.  I think the I in GIF stands for Interchange.  :-)

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

Sure, my point is simply that once you push things down to the
filesystem layer, there are a large number of ways to share the data
out.  And I would advocate not making things *too* specific to any one
technology.  Every technology has some pros and cons, so the more
flexible the overall design, the easier uptake will be.

For instance, last I checked the git Windows client is still under
development, so for projects like Mozilla a firm git requirement might
be a showstopper.  For projects that are SVN-based, if an SVN-varient of
the system could be used (and interoperate with the GIT-based versions),
then they will be happy as well.

Bryce



More information about the Desktop_architects mailing list