[cgiapp] Re: Status of upcoming release?

[Christopher Hicks]

On Fri, 24 Sep 2004, Myk Melez wrote:
> 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.

I have no objection to implementing features that make sense in the 
bugzilla context, but I'm not sure which things should be in which 
context.  I'm not trying to compete with BZ at all.  I like BZ.  I want 
more people to use BZ.  I'm lazy and I have no interest in reinventing the 
wheel which BZ had refined already far better than anything else I've ever 
seen.  If anyone has any question about my motives don't be afraid to ask 
onlist or off.

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

I don't object to doing things that way that make sense to do that way. 
I'm looking forward to the CSS skinability work that folks are doing too. 
I'd really like to have everything in my development suite look like it 
was meant to go together instead of a farm house with 150 years of sheds 
stuck on the back.  :)

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

I appreciate you putting the time into considering these.

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

I have no objection to using whatever of this is implemented in bugzilla 
at any given time.  My goal here is to not compete or overlap with 
bugzilla functionality at all.  For something where there's a popular 
patch already available putting together a FullyLoadedBugzillaSuperset I'd 
like to include that patch.  For very controversial (or very boring) 
things this could be an opportunity to get wider testing of features that 
are pending to go into the core bugzilla.  If such a patch or something 
functionally equivalent got applied to bugzilla we'd stop patching our 
version.  If such a patch was decided that it was not worthy of being in 
the OneTrueBugzilla then the value of maintaining the patch versus the 
value of the feature would have to be weighed with my tendancy being 
toward dropping it or reimplemnting the feature in a way that worked in 
parallel instead of in patch to bugzilla.  Does this philosophy bother 
anyone?

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

I'm not trying to recreate the wheel.  I'm trying to take the various 
pieces and provide an easy way for people to get it installed that doesn't 
require them setting up the integration points by hand.  I haven't looked 
at lxr's guts, but I've enjoyed using it.  cvsmonitor is another fine 
example of something that I seen no need to recreate in the forseeable 
future that would be beneficial to have integrated.

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

A wiki may not provide any benefit to bugzilla, but it it can be very 
beneficial in a larger project sense.  I'm not sure whether it was in 
private email or something on a mailing list, but one of the folk who 
responded with interest suggested having two wikis per project - one for 
user documentation and one for development documentation.  This makes a 
lot of sense to me and closely mirrors what we've done emergently on our 
projects using one wiki.  But if you have one fixed wiki that's going to 
be involved with a project, then you can do some interesting things.  For 
one, the data dictionary for the project could be maintained through the 
wiki interface.  Changes to the data design would need to be updated into 
subversion.  Some script for migrating the data would need to be created, 
but could be autogenerated for the common case of adding a new column. 
This subversion event should be picked up and shown in the bug with a link 
that takes somebody into the wiki so that they could see the change in 
context or a link into lxr to see the underlying code and version history.
Do you see where I want this to go?

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

Absolutely.

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

There's been a lot of prior discussion on the list about this.  I maintain 
that tasks are semantically different and should be treated in a somewhat 
different fashion.  I find that I have a single bug that starts of with a 
couple of things that need to be done within it.  That leads to a few 
other things needing to be done and so on.  I could (as some have 
suggested) track this evolving task list by making bugs for the individual 
tasks.  This seems like a painful amount of overhead for me and it 
violates the semantic difference between a bug and a thread for me 
personally.

>>  - 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 can respect the reasons for maintaining a pure focus for bugzilla at the 
same time as I really want something that isn't so pure.

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

That's totally fine with me.

> Additional project management features in Bugzilla for lightweight 
> project management would have to be tackled on a case-by-case basis.

Billing is one piece that we've got hacked together now that I'd like to 
see done in a way that other people could use it an build on it.  Time

> What is it you're looking for?

- Time forecasts (how many bugs will I kill this week if I work six hours 
a day?)

- the ability to assign multiple people to a task and disproportionately 
allocate time to them and forecast completion times for each person based 
on that.

- graphs showing time worked history

- graphs for forecast which projects will be using time which days for the 
next two weeks.

>>  - Web, XUL, and SOAP interfaces
>
> I'd love to have a XUL interface to Bugzilla.

I'm shooting a bit higher.  I want a XUL interface to all the stuff I 
talked about above ultimately.  :)

> I did some work on one a while ago (Bugxula 
> <http://bugxula.mozdev.org/>),

Which I've actually used a few desktop boxes ago.

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

I'd certainly like to use what you've done as a starting point.

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

Yay.

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

I'm pretty comfortable with the database layout of bugzilla for getting 
the various pieces of data out that need to be displayed.  For 
manipulations I'm guessing I should use the new object-oriented Bug 
interface, but I haven't looked at that and I don't remember how far that 
is along.

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

More than once I've been somewhere and I'll start working on a bug comment 
and I need to be more research before I finish it and I have to decide 
whether to sit down and do the research while I'm onsite or kill the 
comment I've started and redo the whole thing when I get home.  If I could 
checkpoint the comment in progress without posting it to the bug, and 
reopen it at home it would eliminate a lot of "???________fill in____???" 
sorts of things that show up because I'm too lazy to redo the whole thing 
later and i just enter it half-done and then rewrite and repost the whole 
thing once I have time/brain/etc. to finish it.

The other issue is that I may do work on one day and not put it in until 
the next day.  I bill off of BZ, so if I'm a slacker and don't get my time 
in on the same day that the work is done the bills look funny and its 
harder to match up the BZ entries with the calendar when trying to figure 
out what happened when.

Does that make more or less sense now?  :)

-- 
</chris>

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare