Re: gforge

On Wednesday 26 November 2003 11:00, Dave Page wrote:
> > -----Original Message-----
> > From: Marc G. Fournier [mailto:scrappy@postgresql.org]
> Mainly because we prefer the traditional mailing lists + CVS approach
> like the core server uses. We also have a multilanguage website that
> gborg can't do, but then I'm not sure that sf.net can either (for
> example).
>

I'm pretty sure you could do your multilingual support on sf, though I'd need 
to look at your code to know for sure. sf gives you a standard user account 
ish web directory so its pretty flexible; the only big downside that I ever 
saw was they only give folks access to mysql databases, not postgresql :-(  
As for standard mailing lists / cvs approach, theres no reason you couldnt 
approach a sourceforge project the same way.

BTW - I've been meaning to ask why don't we use the pgadmin code's language 
approach for the main website?

> Probably better people to ask would be Robert or Chris K-L, as they
> actively chose sf.net as an alternative to GBorg.
>

I think the original rational for it was that great bridge had shut things 
down, so things were switched to sourceforge and when gborg came up there was 
no reason to switch back.  

speaking from a personal standpoint as someone who is a member of projects on 
both sites and has looked at the backend code for both sites, I do feel the 
sourceforge code is superior to the gborg code.  from a project standpoint I 
think the information is laid out better both per project and on the site as 
a whole... for example the is no way to search for a specific project on 
gborg.. another example is the urls for each given project, compare:
http://gborg.postgresql.org/project/pgweb/projdisplay.php 
vs. http://sourceforge.net/projects/phppgadmin/
minor, but the latter is better in the grand scheme of things. you can also 
specify a different project home page from the development page.  
another thing I like about sourceforge better is its use of various ssh tools 
for things like ftp and cvs access.   

of course there are other intangibles that neither a gforge or a gborg will 
give you that you get from sourceforge such as more exposure and thier built 
in mirror system. 

> > Again, note, I'm neither here nor there on this ... it was
> > suggested, so I started to play with it to see what it could
> > do ... if its just a matter of taking cues from gForge and
> > bring them to gBorg, that's cool too ...
>

Of course the problem with that is that it requires someone to actually sit 
down and code it. The biggest advantage i would see from moving to gforge 
instead of gborg is that someone else would be developing it.  Even now 
people are contributing to that code features like gant charting, 
localization, and soap server support... i may never need this but its a 
least a good sign to see things like this being implemented.  

> My major concern is the confusion that 2 parallel project sites will
> bring, or the chaos that an attempted migration is likely to cause.
>
> I don't see an easy win that won't take significant planning.
>

Well, i think there are facts here that we just dont know, like how many 
people don't use gborg because of its current implementation? Marc says he 
has heard these complaints before so there must be something to it.  The 
other thing is how many projects on gborg are actually active? I'm guessing a 
lot of those projects would not have to be moved since no one is actually 
using them...   I agree that having two sites would probably be confusing, so 
you'd have to push everyone from one site to the other which would take some 
effort. If people are against the idea then I don't think it should be pushed 
on anyone, however that's the kind of attitde that tends to lock people into 
outdated technology. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL