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
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
