/me puts on his asbestos suit in preparation for responses...
I've been using search.cpan.org for several years now. I've also been using GForge (as SourceForge and Rubyforge) for a couple of years now and I have decided something: GForge is better.
No, it has nothing to do with the navigation, and I'm certainly not in the "CPAN sucks" crowd. Besides, I know that search.cpan != CPAN. :) So, why do I think it's better? Hmm..that's a little more difficult for me to describe, but let me give it a shot.
First, there's RT (/me ducks rotten vegetables from jonasbn). I'm not saying it's a bad tool. I'm just saying I don't like it. The interface just feels clunky and I seem to have a hard navigating properly (anyone remember my earlier debacle?). With GForge, you get ye old familiar "Tracker", which comes with a handy set of predefined items (Bugs, Feature Requests, etc), and is easily configurable. I find it much easier to track bugs, and navigate through bug-related posts.
Second, there's forums and mailing lists. Rather than having folks send you individual emails, they can post to your custom mailing list, or the forums, which other people can then read and/or search on. I suppose I should ammend my earlier feelings on mailing lists at this point to say that I don't mind subscribing to mailing lists *IF* they are low-traffic.
Third, CVS, and everything that comes with a version control system.
Fourth, and this ties back into CVS, the ability to add other project members and delegate tasks. For simple modules this isn't much of a feature, but for some of the larger ones (DBI, Net::SSH::Perl, etc) this could be very helpful.
Fifth, the ability to group related modules under a single project. This is more of a "warm & fuzzy" kind of argument, I know. This partially ties back into task delegation. You could have a series of XML related modules, with different authors, all under the same project. Or perhaps a few different modules grouped together that are related by a dependency of some sort.
Sixth, the ability to monitor releases. I like to know via email when a package of interest has been updated. More than once I've missed a release on CPAN because I wasn't paying attention.
Seventh, I get my own project home page. There are plans in the works to add project wiki's on Rubyforge, so I think it's customizable.
Ok, now let's talk about the drawbacks. The first "problem" is that GForge is written in PHP. I mention this because I suspect there's a lot of pride in the Perl community. The sort of pride that might insist that any Perl related repository be written in Perl. Maybe I'm wrong. The Ruby community, wisely I think, decided that reinventing the wheel just to give themselves a warm, fuzzy feeling was a bad idea and decided to use a good tool was already available.
The second problem I see is the lack of a command line interface. Someone would have to write a new interface for the now-mythical www.perlforge.org. It's do-able, though.
The third problem is...people are *used* to search.cpan.org and it might take some time to get folks to switch to something like a PerlForge.
Maybe there are some other problems I haven't thought of. I'm sure you will let me know. ;) Oh, and please, please, please, don't take this as a "I hate CPAN" rant or anything. I know there are several folks here who are near and dear to search.cpan.org and have put a lot of work into it (which I and most others certainly appreciate).
I mostly mentioned it to see how other people here feel about a possible PerlForge.
That is all.
Update: I accidentally said Python instead of PHP originally. Fixed.
As far as setting up "PerlForge," why bother? SourceForge works great for Perl projects!
-sam
Re:Apples and Oranges?
djberg96 on 2004-05-02T17:46:34
Ok, perhaps I conflated CPAN with PAUSE, although the fact that we're talking about 3 systems (CPAN, PAUSE, search.cpan) instead of 1 reinforces (in my mind) the need for consolidation.Also, search.cpan.org is a search engine but it also does ratings (tied to the ratings engine) and bug tracking (tied to RT), so it ends up feeling like it's somewhere between a development environment and a search engine. To me, anyway. Yes, I know it's a front end.
Yes, some folks have posted their stuff on Sourceforge. But, I thought a "PerlForge" would be a neat idea, in that it would provide "one-stop-shopping" for Perl-only projects and could be tailored as such. See http://www.rubyforge.org for an idea of what I mean.
Also, SourceForge's FRS sucks.
Re:Apples and Oranges?
perrin on 2004-05-03T16:31:36
PerlForge might be a neat idea, but it still has little to do with CPAN or search.cpan.org. The purpose of such a site would be to assist in development, as opposed to assisting in distribution, which is what CPAN does. I think it's very reasonable to separate the two.
Re:PHP, not Python
djberg96 on 2004-05-02T18:47:05
I've been lied to! Thanks. I'll update my entry.
Re:Use both
djberg96 on 2004-05-03T20:41:05
Well, I never looked but I assumed that GForge had an API that let you do everything programmatically that you can do via a web interface. Is that not so? If not, I can see where there would be a problem.I'd still prefer a PerlForge to just using vanilla SourceForge. For starters I have always thought SF's FRS was both bizarre and dumb. Also, SF seems to have a lot of downtime lately. And, like I mentioned, you could taylor it for Perl users.
Re:Use both
pudge on 2004-05-04T22:54:07
I use both too. For my projects, I use SF.net for web space, distribution, and CVS. I use rt.cpan.org for bug reports. I stole some of bdf's ideas and use his release script (now Module::Release) for it all. I add a simple web page pulling it all together.
In short, a CPAN hosted set of mailing lists relating to published modules, would be rather nice, as it's likely a big burden for module authors to set one up all by himself.
I assume this is precisely what you're talking about, for the hypothetical PerlForge, no?
