[cgiapp] Re: Status of upcoming release?

[Myk Melez]

Christopher Hicks wrote:

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

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.

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.

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:

>   - SVN/CVS/Arch integration

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.

>  - source code browser

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.

>  - integrated wiki

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?

>  - links between source code browser, bug tracker, and wiki

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.

>  - tasks

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?

>  - project management

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.

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?

>  - Web, XUL, and SOAP interfaces

I'd love to have a XUL interface to Bugzilla.  I did some work on one a 
while ago (Bugxula <http://bugxula.mozdev.org/>), 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...

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.

>  - server side written Perl (obviously)

Sure.

>  - checkpoint new comments in progress without posting them
>  - ability to predate comments so that time entries can be added 
> asynchronously to when the work is done

I don't understand these.  Can you elucidate?

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20040924/24f53bda/attachment.html>