[cgiapp]/[devs.bz] SVN with integrated bug tracker

[Christopher Hicks]

[this thread was started on the bz mailing list after a discussion on the 
cgiapp mailing list.  For those folks on the cgiapp mailing list getting 
cc'd on this for the first time, check out
http://bugzilla.org/cgi-bin/mj_wwwusr?user=&passw=&list=developers&brief=on&func=archive-get-part&extra=200409/85
to get caught up.]

On Fri, 24 Sep 2004, Peter Masiar wrote:
> Another similar project is GForge, GPL fork of SourceForge. In PHP.

I've not looked at it recently.  Does anybody have any experience with it?
I'm willing to consider any features that people would like to see 
eventually.

But one of my sincere motivations is to end up with a pure Perl solution 
eventually.  So if GForge would be a good place to start in terms of 
database design or features, we could use pieces of it while we're 
building other things.  We don't have to be pure perl from the beginning.
But we'd need somebody willing to code in PHP to smooth over the rough 
edges in the mean time.

> Basically both PHP and python have 'integrated project repository' app 
> which every software shop needs, as a start of hacking - but perl 
> community as usual tries TIMTOWDI. If this 'integrated bug tracker' was 
> C::A based, it would be smart way to sneak C::A to perl shops.

Yes, but at least personally I'm more interested in pushing Apache::ASP 
out into the world.  But if you're willing to step up and do the web 
portion of things I'm certainly happy enough to leave such decisions to 
you.

> Does it mean developing new BZ+, based on C::A framework?

Nothing is set in concrete yet.

>> 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.
>> 
>> Off the top of my head this is what I'm hoping to achieve:
>> 
>>  - SVN/CVS/Arch integration
>
> I would go for SVN first. CVS is past, and Arch has different philosophy (is 
> distributed). SVN server is central code repository, and natural place for 
> central bug tracking database and wiki with project docs.

We're on the same page here.

>>  - source code browser
>>  - integrated wiki
>
> There was (a year ago) one project in East Asia (IIRC Taiwan), using RT 
> bug tracker framework and Kwiki wiki engine, but then they had all docs 
> in chinese - then :-(

Personally I'm leaning toward TWiki, but I'm not a wiki afficianado except 
for occassionally using wikipedia, so I'm very open to suggestions here.

> Kwiki rather easy to install and was simple in previous version, but 
> it's not using CGI:App based framework. But I heard Kwiki author, Ingy, 
> is from Portland and a friend of Ward Cunningham, of the first wiki 
> fame. Thay want to implement FIT test framework into Kwiki. Ingy is also 
> paid to work FT on wikis for Social Text.

Sounds cool.

> I also prefer wiki which stores page as text files (with metadata if 
> needed), and not in database.

Agreed.

> Because if you have SVN, why not to use it for keeping track of versions 
> of wiki pages, right?

Absolutely.

> As a fact, I'll suggest to for every project to have *two wikis*
> (1) technical docs, meeting notes, XP iterations and what you have
> (2) second separate wiki with user's help pages - web-based help is IMHO 
> natural for web-based apps.

Yes, yes, yes.

>>  - links between source code browser, bug tracker, and wiki
>
> Exactly. Very important.
>
> So ie you can enter wiki markup [[bug:1234]] in code comments, and it will be 
> linked to hyperlink to a bug number 1234 in BZ when viewed in code browser.

!!! :)

> IIRC there was perl-based CVS viever, but it is obsolete now and viewCVS is 
> standard - again python-based. :-(

cvsmonitor is nice as well.

>>  - tasks
>>  - project management
>
> Twiki has plugins for XP-style project management, GPL-ed ideas can be 
> stolen, but Twiki codebase is a mess.

If Twiki does what we want in most respects that would prevent it from 
being a stop gap.  I wasn't impressed with the layout of how stuff got 
installed if you followed the instructions, but I didn't see anything else 
that horrified me when I installed it, but that was a year ago.

> Also GForge handles projects, with graphs and all.

[In neanderthal man voice.]  Want more graphs to print on color printer!

I've never felt the sourceforge graphs were anything beyond functional. 
That's an area that BZ does better about in the areas that BZ graphs.

>>  - Web, XUL, and SOAP interfaces
>>  - server side written Perl (obviously)
>>  - 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
>
> Not sure about usecases for this functionality. Will page versions in wiki be 
> enough for this?

Maybe.  The use case is that if somebody is on site and putting time and 
notes into a PDA then it may be a few days before that gets transferred 
into bugzilla.  For purposes of billing being able to have the "effective 
primary date of the note" be different than the "actual real time that 
bugzilla ended up with the note" would make life much easier.  My only 
grief with using BZ for billing is this precise issue.  I'll be happy to 
throw that code into the stone soup naturally.

>> (1) Am I right that going in this direction would be counter to the 
>> express position of the core devs?
>
> Code devs of what package? Bugzilla? Trac? Kwiki? C::A?

Bugzilla.

>> (2) Is there anyone out there interested in doing something like this? 
>
> I am. But I am already spread way too thin. :-(

Then we may be stuck with a Moz client or Apache::ASP!  :)

> Again, this kind of package would be IMHO a great way to promote C::A 
> framework.

I agree.  I've done a few projects in C::A and I liked it.  For doing 
development on this scale I much prefer Apache::ASP though.

> But it is much more work that just creating C::A based wiki, and wiki as 
> example of C::A based app was rejected on the list before - but times, 
> people, and opinions can change? :-)

Its a matter of someone being willing to take the time to code it.  But 
yes, it would be great for the community.

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