<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Christopher Hicks wrote:<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite">But there are still lots of features in Trac that I want,
that look very nice, that would make my life as a developer easier, and
to the best of my recollection that have been declared beyond the scope
of BZ. And I want those features without throwing out bugzilla. So as
far as I can tell to get something like this done we need a new project
to build a superset of BZ's functionality.<br>
</blockquote>
That's not clear at all. First, some of the features on your list are
not beyond Bugzilla's scope, they just haven't been implemented yet.
You could implement those in Bugzilla without forking.<br>
<br>
Others may be beyond the scope of core Bugzilla but would work very
well as an extension (ala Firefox extensions) using our new template
hooks mechanism and a Perl code-equivalent that we plan to implement
soon.<br>
<br>
The rest of the features on your list are indeed beyond Bugzilla's
scope, but that's because they're sufficiently complex and different
that it makes more sense for them to be separate applications with good
integration between the top apps. I don't speak for all core
developers, but here's where the features on your list fall within
those three categories (core feature, extension, or separate app with
integration points) in my book:<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite">
- SVN/CVS/Arch integration<br>
</blockquote>
This should be core Bugzilla functionality, implemented in a way that
allows us to add support for additional revision control tools in the
future just as we currently support multiple authentication schemes.<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite"> - source code browser
<br>
</blockquote>
mozilla.org uses an old, forked version of LXR for this with various
integration points (f.e. when you view a diff in Bugzilla you can
browse to the LXR pages for the files being diffed). Newer and better
versions of LXR and other source code browsers are available. This
seems like very different and complex functionality and something
better maintained as a separate application with good integration
points between the two.<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite"> - integrated wiki
<br>
</blockquote>
Seems like there are so many good wikis out there that a separate
application with good integration points is the better solution, but I
also don't understand the problem a wiki is trying to solve here. What
benefits would an integrated wiki provide to Bugzilla?<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite"> - links between source code browser, bug tracker, and wiki<br>
</blockquote>
The links between Bugzilla and the other apps should be a part of core
Bugzilla, as they are now for Bugzilla->source code browser links.<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite"> - tasks
<br>
</blockquote>
I probably don't understand this item, since for me tracking tasks is
what Bugzilla does. Can you explain the difference between Bugzilla
bug reports and tasks?<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite"> - project management
<br>
</blockquote>
We've resisted making Bugzilla a project management tool for a while,
even as project management features have crept into the application
(f.e. the time tracking code, but also longstanding features like the
target milestone field). I think it's OK to have some lightweight
project management functionality in Bugzilla, as there is today, for
shops doing the kind of development that doesn't need a heavyweight
tool like Microsoft Project (like mozilla.org incidentally), but
complex needs are better served by a specialized application.<br>
<br>
Additional project management features in Bugzilla for lightweight
project management would have to be tackled on a case-by-case basis.
What is it you're looking for?<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite"> - Web, XUL, and SOAP interfaces
<br>
</blockquote>
I'd love to have a XUL interface
to Bugzilla. I did some work on one a while ago (<a
href="http://bugxula.mozdev.org/">Bugxula</a>),
and since I don't have time to work on it these days I'd be happy to
turn over that code to someone who wanted to develop it further. Note
that Bugxula is an independent desktop application, not a core
component of Bugzilla, and this model would probably work best for a
web-based XUL application as well--we just need to build out Bugzilla's
programmatic interfaces, which brings me to SOAP...<br>
<br>
I'm sanguine about SOAP, preferring REST for its simplicity, adherence
to web principles, and popularity (most requests to Amazon's web
services API are to its REST version), but I'd be willing to see a
high-quality and well-maintained SOAP implementation become part of
Bugzilla proper. This might do better as an extension however, at
least at first.<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite"> - server side written Perl (obviously)
<br>
</blockquote>
Sure.<br>
<br>
<blockquote cite="midPine.LNX.4.60.0409231014580.18213@skippy.fini.net"
type="cite"> - checkpoint new comments in progress without posting
them
<br>
- ability to predate comments so that time entries can be added
asynchronously to when the work is done
<br>
</blockquote>
I don't understand these. Can you elucidate?<br>
<br>
-myk<br>
<br>
</body>
</html>