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 _______________________________________________ Desktop_architects mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
