Re: gforge

On Wednesday 26 November 2003 11:00, Dave Page wrote:
> > -----Original Message-----
> > From: Marc G. Fournier [mailto:scrappy(at)postgresql(dot)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