[cgiapp] SVN with integrated bug tracker Was: Status of upcoming release?

[Peter Masiar]

Christopher Hicks wrote:

> On Thu, 23 Sep 2004, Peter Masiar wrote on the cgiapp mailing list:
> 
>> If you are interested in using SVN, you might be interested also in 
>> TRAC: GPL-ed integrated source code archive, bug/ticket tracking, and 
>> wiki. Really integrated, commit message "fixied bug #123" will close 
>> it in bug tracker, code diff can link to bug description, comment in 
>> bug tracker can link to wiki page, and back. Pretty neat as free 
>> software goes.
>>
>> http://www.edgewall.com/products/trac/
>>
>> Warning: it's in python.
>> I am sorry nothing fully integrated like this is available in perl, 
>> AFAIK.
> 
> To me this is a truly sad state of affairs.  Trac is a fine example of 
> what can be done on the web these days.  

Another similar project is GForge, GPL fork of SourceForge. In PHP.

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.

> It's also lacking real database 
> support, many of the nice features of BZ, and its written in that 
> space-scoped language that has syphoned off a few of Perl's 
> practitioners. 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.  

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

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

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

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.

I also prefer wiki which stores page as text files (with metadata if 
needed), and not in database. Because if you have SVN, why not to use it 
for keeping track of versions of wiki pages, right?

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.

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

>  - tasks
>  - project management

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

Also GForge handles projects, with graphs and all.

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

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

> (2) Is there anyone out there interested in doing something like this? 

I am. But I am already spread way too thin. :-(

Again, this kind of package would be IMHO a great way to promote C::A 
framework. 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? :-)

> I've got folks here on staff who I can get to generate the XUL and 
> related JS/CSS to make an attractive mozilla-based client.  They all use 
> BZ and share my frustrations to some degree so I don't think it'll take 
> a lot of arm twisting to get a nice interface together.  That leaves the 
> SOAP server which I'm happy to do large chunks of and the web interface 
> which I could care less about.
> 
> (3) What would you like to see in a BZ superset, IDE sort of thing?
> 
> (4) I recall somebody doing cvs integration and posting about it on the 
> list.  Has anyone done something similar for svn?
> 


-- 
Peter Masiar