Subject: Collaboration Tool Proposal

From: Josh Berkus <[email-masked]>
Date: Thu, 26 Feb 2004 09:12:53 -0800

Folks,

Discuss/vote/object/scream&shout:

PROPOSAL: GBorg --> GForge Migration

Why do we want a full-service collaboration tool?

PostgreSQL is no longer a monolithic project,
but rather a collection of closely related projects.   Some of
these projects are official, some are unofficial, some are
abandoned, some reside in Gborg and some in /contib and the
logic to the separation is not readily apparent.
Some of these "child projects" are substantial, having
several developers and their own communities; others are
maintained by the same core members and major contributors
who do most other things.  Worst of all, some key projects,
like phpPgAdmin, are not hosted with us at all, making them
very hard to identify by new users. A high-quality,
full-service community & development tool will help these
"child projects" be more visible and yet more modular and
independant at the same time.

Further, currently bug tracking and TODOs are maintained by
e-mail and Bruce's personal web pages.  This is fine for us, but
rather impenetrable to the newcomer or IT support person,
and can dissuade new members from joining our community.  Also,
 the lack of a more sophisticated issue tracking tool is handicapping
 when it comes time to beta-testing releases; at least one bug
made it from beta into 7.4.0 simply because there was no
follow-up on a patch.  While an online bugtracker won't replace
having a "beta test master", it will make that person's job
easier.

Finally, most other major OSS projects are using collaboration
tools for their infrastructure, and find them indispensable.
Particularly well-known tools make it easier for new developers
to get acquainted with the project and get started coding faster.
With the incipient possibility of new, corporate-sponsored
contributors to our project, having a ready and easy to understand
structure for them to join is vital.   The
structure of tools like SourceForge and Savannah are familiar
to most people in the OSS programming space.

Why do we want to replace GBorg?

GBorg was pretty good collab tool technology for 2000.
Heck, it's still not a bad tool. Unfortunately, since the
demise of Great Bridge, it's had only one maintainer (for
whose efforts we are very grateful), meaning
that little or no progressive development has taken place.
For example, GBorg still lacks both project and bug search
features, and based on our community is unlikely to develop
these things.

There are several other collab tools created supported by
their own communities, which are being actively maintained
and developed by them -- meaning that we can expect to continue
seeing & receiving new features without having to code them
ourselves.  It's what open source is about, hey?

Why GForge?

GForge runs on PostgreSQL and their team are enthusiastic PG
users.  Most other collab tools run on other databases and would
have to be ported.   Further, the GForge community is excited
about us adopting it and is willing to provide assistance &
advice to us.  Both Tim Perdue and Chris DiBona have sought
me out to offer their help with migration & setup.

GForge, being the OSS fork of the now-closed SourceForge,
presents a reasonable familiar interface to people familiar
with OSS projects.  However, unlike SF, GForge has continued
to develop and improve.

GForge has a number of additional features that we would find
useful.  For example, the "Code Snippets" feature fills in the
desire for a "PL-code CPAN" that we discussed last fall,
replacing Roberto Mello's moribund "PL/pgSQL Library".  There
is a "TODO" organizer (Tasks).  The is a News feed.
There is even web-forum support in the unlikely event we
want it.  The "My Page" feature allows developers to
quick-reference the projects they are working on.

But check it out for yourself: www.gforge.org

What does GForge lack?

Currently, GForge does not have any kind of plug-in for
full project home pages; this would still be ad-hoc.
As well, the integration with CVS is kind of hackish
(PHP wrapper for CVSweb).   And the bug tracker, while
more sophisticated than we have currently, does not
measure up to BugZilla or Jira.

There is, in fact, a mailing list feature, it's just
not shown on the test site.

However, with a couple hundred using sites and 2 companies
doing professional GForge support, it seems reasonable
to expect those things to come along soon.  And it's
significantly possible that we could encourage new
features by lobbying the GForge community.

What are our alternatives?

It is possible that there is a better tool than GForge
out there somewhere.  I just haven't been able to find it.

We could stick with GBorg, and try to make some 
incremental improvements to it.    We would also want
to then adopt an external bug tracker (Bugzilla, Jira, DCL,
something) for the main project, at least.   Personally, I see this option as 
one that we will have to pay for a year from now, when we *still* haven't 
made the improvements we've talked about.

How can we do the migration?

Sloooooooooowllllly.    My thought is that, immediately,
only new projects and people who are enthusiastic about
GForge would migrate.   Other projects would migrate at
convenient times for them, and as we can get volunteer help
for the process.  I see this migration process taking maybe a
year.

At the same time, we would set up a bug tracker on GForge
for the main project in preparation for 7.5.   If this works
well, we could discuss moving other portions of
developer.postgresql.org to GForge.   This would give the
main project a degree of transparency it has previously
lacked.

And, of course, we would assess at each step whether or not
the migration was a good idea.

I will volunteer to be the GForge administrator, although I will happily give 
someone else that honor if anyone steps forward.

But I don't want to migrate my project!

See above.  You'd have at least a year to procrastinate about it,
and may be able to get someone else to do most of the
migration work for you.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: Joseph Tate <[email-masked]>
Date: Thu, 26 Feb 2004 12:53:26 -0500

Josh Berkus wrote:

> Discuss:

Has anyone talked to the people at collabnet (http://www.collab.net)?  I 
wonder if they'd be willing to put something together for the PostgreSQL 
team?  They run the tigris.org site, which is one of the nicest OSS 
collaboration sites I've worked with.  GForge is nice, but seems more 
kludgey than Tigris.

What does the Apache project run?

Another option is something like Drupal (http://www.drupal.org).  Drupal 
is a CMS system with tons of plugins.  I'm not sure that it could handle 
a project as large as PostgreSQL, but Drupal's own development work is 
self hosted.  It may merit some investigation.

---

From: Josh Berkus <[email-masked]>
Date: Thu, 26 Feb 2004 10:19:23 -0800

Joseph,

Thanks for feedback.

> collaboration sites I've worked with.  GForge is nice, but seems more 

Collabnet is not OSS.   We would be dependant on their charity (and 
profitablity)  to host us, which has not been The PostgreSQL Way (tm) to 
date.   Also, as a former OpenOffice.org Project lead, Collabnet is not very 
responsive to user feature requests unless they are backed by $$$$.   It's 
the way proprietary software works.   Last time I was involved (late 2002), 
all web management on CN was done via CVS, which meant that everything, 
including news items, needed to be coded in raw HTML.    Not the direction we 
want to go in.

Believe me, I considered CN, because it *is* an excellent code management 
tool.  But it's not OSS and the community management support isn't there.

> What does the Apache project run?

Not sure.   Anyone?

> self hosted.  It may merit some investigation.

Nope.  Drupal is stricty community; it doesn't do project/code management.   
Also it doesn't scale (and isn't intended to).

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: Robert Treat <[email-masked]>
Date: 26 Feb 2004 13:45:29 -0500

> > What does the Apache project run?

Apache uses a home-brew collection of OSS tools. I think they have the
advantage of a larger community of web developers to help out than we
have ;-)

Josh, are you still in favor of this move if the larger community does
not want to move the main project to a gforge based system? or vice
versa?

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

---

From: Josh Berkus <[email-masked]>
Date: Thu, 26 Feb 2004 10:49:46 -0800

Robert,

> not want to move the main project to a gforge based system? or vice

Not sure.   Depends on what the leads of the associated projects think.   
Obviously, if everyone's dead set against it, we won't do it.

However, keep in mind that this is a proposal to *try* migrating to GForge.   
We can reverse the process if we decide it's not worth it.  That's why I'd 
like to start with a few projects at a time.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: "Jeroen T. Vermeulen" <[email-masked]>
Date: Thu, 26 Feb 2004 20:00:43 +0100

> Obviously, if everyone's dead set against it, we won't do it.

I for one am willing to try this in the near term.  I've got an external
domain (pqxx.tk) pointing to the libpqxx page on GBorg, and moving it over
to a new URL is child's play.  My main worry is transition management:

 - How will mailing list subscribers be affected?
 - How will CVS users be affected?
 - Can the mailing list archives be moved over?
 - Where will my old bug reports and corresponding discussions go?
 - Can FAQ entries be copied over automatically?
 - Is there a way of migrating these services one by one?

If it takes some scripting and/or programming to do some of this, I'm
willing to help insofar as I have time.

Jeroen

---

From: Josh Berkus <[email-masked]>
Date: Thu, 26 Feb 2004 11:07:03 -0800

Jeroen,

> I for one am willing to try this in the near term.

Great!

> I've got an external

Either Tim, Chris, or both will help with this.    If we can't migrate 
everything by script, we'll have to give up on the idea.  Some projects, like 
JDBC, have huge mailing list archives.

I think you would want to do the migration "all at once", though.   Putting up 
a page explaining that the CVS is on GForge but the mailing lists are non 
GBorg for a week would confuse the heck out of people, I think.

Since both systems are based on postgresql databases, migration should be the 
simple expedient of writing the right Perl/PHP+SQL script.

> willing to help insofar as I have time.

Terrific!

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: David Costa <[email-masked]>
Date: Thu, 26 Feb 2004 21:05:34 +0100

On Feb 26, 2004, at 6:53 PM, Joseph Tate wrote:

> Josh Berkus wrote:
>
>> Folks,
>> Discuss:
>
> Has anyone talked to the people at collabnet (http://www.collab.net)?  
> I wonder if they'd be willing to put something together for the 
> PostgreSQL team?  They run the tigris.org site, which is one of the 
> nicest OSS collaboration sites I've worked with.  GForge is nice, but 
> seems more kludgey than Tigris.
>
> Another option is something like Drupal (http://www.drupal.org).  
> Drupal is a CMS system with tons of plugins.  I'm not sure that it 
> could handle a project as large as PostgreSQL, but Drupal's own 
> development work is self hosted.  It may merit some investigation.

Drupal? I would not recommend it.  WIth every plug and play CMS you get 
what you pay for aka when you need to change something, you are in 
trouble and you end up searching their classes and grasp to understand 
they way they code in php.

Is this as an alternative to gborg or the current website ? As far as I 
know drupal has nothing like bug tracking etc. for sure GForge (to me ) 
is way better then drupal :D

Thanks
David Costa

>
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 26 Feb 2004 21:16:38 +0100

> Why do we want a full-service collaboration tool?

In terms of improving the hosting infrastructure, this would surely be a 
step forward, but the problem with "collaboration" is not that the 
tools are missing, it's that people are unwilling to use any tools for 
issue tracking, etc.  This is in fact a near-universal problem.  If you 
look at sourceforge, very few projects actually use any of the 
"collaboration" tools.  If you want to get the project to do something, 
you still have to use email and CVS.  And with those projects (not 
necessarily on sourceforge) that have a sophisticated bug tracking 
structure, the sheer number of filed bugs is so large and irregular in 
quality that the bugs are in fact meaningless.  (Oddly enough, the 
projects I have in mind here do *not* use a full-service collaboration 
tool, just a bug tracker.  Make of that what you will.)  So yes, I 
think this is a reasonable plan, just don't expect "collaboration" to 
suddenly appear out of nowhere.

---

From: "Jeroen T. Vermeulen" <[email-masked]>
Date: Thu, 26 Feb 2004 21:28:22 +0100

> suddenly appear out of nowhere.

One thing that helps a lot in my experience is the ability to manage bug
reports.  On gborg, for instance, I'm stuck with several dozen duplicates
from a time there were technical problems with the site; lots of "semantic
garbage" in the form of people making silly assumptions, not reading
earlier bug reports, or asking generic C++ questions; requests for features
that are already there; support requests and other irrelevant issues; and
multiple reports covering the same underlying problem.

If I could merge, delete, categorize & group these requests the list would
be a lot easier to manage.

Jeroen

---

From: Josh Berkus <[email-masked]>
Date: Thu, 26 Feb 2004 12:28:44 -0800

Peter,

> So yes, I 

Yeah.  As my grandfather used to say, "You can lead a horse to water, but you 
can't make him shrink."  (granddad is under care, now).

Everyone:  Further data: if we prefer BugZilla to GForge's lighter-weight bug 
tracking, it turns out that there is a BZ plug-in for GForge. 

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 26 Feb 2004 15:41:26 -0500

>tracking, it turns out that there is a BZ plug-in for GForge. 

Perhaps when BZ supports PG - some progress is being made on that front, 
but it's not a done deal yet.

cheers

andrew

---

From: David Costa <[email-masked]>
Date: Thu, 26 Feb 2004 22:03:36 +0100

> features, and based on our community is unlikely to develop

+1 for me. I think the bug tracking is a must.  I have some experience 
with bugs on php.net
(http://bugs.php.net/) and the excellent platform makes the volunteers 
work much easier.

> users.  Most other collab tools run on other databases and would

Again +1, they run PostgreSQL their project is made for postgresql (and 
this is rare in the PHP world) it makes sense to me.
> and may be able to get someone else to do most of the
I would be glad to help, gforge is a PHP based project so I could try 
something out. I don't think that
we (or better said gborg developers) should be scared about the move. 
It is always a pain to migrate but, if it is worth the effort (and in 
this case
we could all benefit from a more structured system) we have to do it.

The suggestion is to move slowly, so, worth a shoot.

Cheers
David Costa

---

From: Robert Treat <[email-masked]>
Date: 26 Feb 2004 16:04:09 -0500

> but it's not a done deal yet.

I can't imagine the BZ plugin for Gforge would require you to use a
second database system would it?  Besides which we can always use red
hats bugzilla port if need be.  I know people have a lot of issues with
it, but if it works for a project of red hats size, i think it would
work for us...

Robert Treat

---

From: Jean-Michel POURE <[email-masked]>
Date: Thu, 26 Feb 2004 23:11:26 +0100

> issue tracking, etc.  

I quite agree with Peter. Most sub-projects have one or two lead developers, 
who organize themselves. In the case of PostgreSQL, the problem is not 
developer intelligence, PostgreSQL project already host the best brains.

On a different level:

I feel that new-comers to PostgreSQL have a hard time finding the right tools, 
installing and starting PostgreSQL, connecting locally, etc...

We probably never hear from these users, as they never reach the first 
connection. In a way, PostgreSQL is targetted at an "elite of hackers".

At pgAdmin, I started a (very) experimental project of mass-download:
http://www.pgadmin.org/pgadmin3/advocacy.php#list

There are no precise statistics, we do not know yet the impact of releasing
pgAdmin III on so many sites. And PostgreSQL Win32 port is not there.

In a few weeks ... with the arrival of PostgreSQL win32 version,
there could be a rush to PostgreSQL, like never before.

A bundle including PHP, PostgreSQL, PhpPgAdmin and pgAdmin III
could reach (at least) 100.000 download every month on:

- PostgreSQL mirrors,
- PHP mirrors,
- Shareware and freeware sites,
- Community sites.

A real flow of people... How are we going to receive them?

My preffered answer would be to use the same techniques that proved to be 
successful. No need to find complicated solutions:

PHP.NET web site proved successful,
let us fork PHP.NET web site

But, do we really want to become the Apache of the database world?
(don't flame me if you think I am becoming mad... I don't think I am.)

If you would like to answer, maybe try posting to 
[email-masked] (no cross-posts).

Otherwise, let us sleep well and make dreams of a better world.

Cheers,
Jean-Michel Pouré

---

From: Tom Lane <[email-masked]>
Date: Thu, 26 Feb 2004 17:29:38 -0500

> hats bugzilla port if need be.

Yeah, I looked into that when core started discussing this whole thing
awhile back.  The Red Hat port of BZ to Postgres is perfectly usable.
Dave Lawrence (maintainer of said port) told me he hopes to see those
changes folded back upstream in another major release or so, at which
point RH will stop needing to maintain a fork.  But in the meantime
we can use their version.  It'd sure beat using You Know Who to keep
track of our own bugs ;-)

I would favor using Bugzilla over anything else just because I'm used
to it (have to use it internally at Red Hat anyway).

			regards, tom lane

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 26 Feb 2004 23:45:05 +0100

Tom Lane wrote:
> Yeah, I looked into that when core started discussing this whole
> thing awhile back.  The Red Hat port of BZ to Postgres is perfectly
> usable.

Is it available anywhere?

---

From: Tom Lane <[email-masked]>
Date: Thu, 26 Feb 2004 17:47:20 -0500

> Is it available anywhere?

Sure, download it off their front bugzilla page:

http://bugzilla.redhat.com/bugzilla/

The link is presently about two paras down in the "News" section.

			regards, tom lane

---

From: Josh Berkus <[email-masked]>
Date: Thu, 26 Feb 2004 14:52:49 -0800

People,

The question is, do we need BZ right off or should we try GForge's lightweight 
tool first?    Personally I find that BZ is a little intimidating to new 
users, particularly for searching on issues; as a result it tends to lead to 
a lot of duplicate filings.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: David Costa <[email-masked]>
Date: Thu, 26 Feb 2004 23:56:45 +0100

> connection. In a way, PostgreSQL is targetted at an "elite of hackers".

Hello,
It could be true. Perhaps a beginner's guide will do the trick.
> A real flow of people... How are we going to receive them?

Not sure if that would really gain consensus. Many PostgreSQL users are 
not into PHP.
I am a volunteer at PHP.net and as far as I see they do not offer a 
bundle.

Then you might get perl users complaining for example. Of course I see 
that other companies
are already  offering such a bundle, NuSphere does 
http://www.nusphere.com/products/index.htm

> let us fork PHP.NET web site

Umh, the php.net code is available on each page via the "source" link. 
That said I am not sure that a clone/fork will be a good start.
We can make the site better with other components without having to 
fork anything IMHO

> (don't flame me if you think I am becoming mad... I don't think I am.)

Not sure but my personal aim is to make the php community aware of the 
fact that PostgreSQL is way better then MySQL and other solutions out 
there.

> [email-masked] (no cross-posts).
Regards,
David Costa, PostgreSQL Advocate http://dotgeek.org
david at postgresql ddoot org gurugeek att php dot net
$dsn = 'pgsql://world:most_advanced@localhost/open_source_database';

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 27 Feb 2004 00:20:37 +0100

Josh Berkus wrote:
> The question is, do we need BZ right off or should we try GForge's
> lightweight tool first?    Personally I find that BZ is a little
> intimidating to new users, particularly for searching on issues; as a
> result it tends to lead to a lot of duplicate filings.

I think we had previously decided that we will not allow a random user 
off the street to file bug reports into whatever system we end up 
using.  I see it primarily as a bug *tracking* system, not a bug 
*reporting* system.

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 26 Feb 2004 18:57:05 -0500

>using.  I see it primarily as a bug *tracking* system, not a bug 

I don't recall that there was a consensus about that. The difference 
between BZ's "unconfirmed" and "new" states is that the latter means it 
has been triaged. See http://bugzilla.mozilla.org/bug_status.html .

I certainly don't think we should impose such a restrictive rule on 
every project that we might host on a GForge installation.

cheers

andrew

---

From: Neil Conway <[email-masked]>
Date: Thu, 26 Feb 2004 21:08:32 -0500

Peter Eisentraut <[email-masked]> writes:
> using.

Uh, why not? (And more to the point, why raise the barrier to entry on
reporting bugs?) 

Individuals can already post to pgsql-bugs "off the street", and it is
not much of a problem. Invalid bug reports can easily be marked as
such.

-Neil

---

From: Cott Lang <[email-masked]>
Date: Thu, 26 Feb 2004 20:57:46 -0700

> but it's not a done deal yet.

Redhat puts out a PG version of Bugzilla. It works pretty well.

However, we just dropped it in favor of Jira. 

Jira is a lot friendlier for the less technically adept, and IIRC, it's
free for open source projects. It's not enough to have something that
can track bugs; you have to have something that people are willing to
use. :)

---

From: Cott Lang <[email-masked]>
Date: Thu, 26 Feb 2004 21:01:41 -0700

> Is it available anywhere?

http://bugzilla.redhat.com/download/bugzilla-redhat-20031120.tar.gz

---

From: Greg Stark <[email-masked]>
Date: 27 Feb 2004 00:17:06 -0500

> to it (have to use it internally at Red Hat anyway).

I might suggest again RT. It's open source and has serious commercial
traction. The postgres port needs a lot of work for it to really catch up to
the original MySQL implementation so most of the users are using it with
MySQL. 

But it works ok under postgres and having more postgres-familiar eyes looking
at it would help polish both its postgres port and fix the problems it exposes
in the postgres optimizer.

It's more of a generic ticketing system than a single-purpose bug tracking
system though. I'm not sure how smoothly it would be usable for bug-tracking
an open source project like postgres.

-- 
greg

---

From: Tom Lane <[email-masked]>
Date: Fri, 27 Feb 2004 00:25:31 -0500

> Uh, why not? (And more to the point, why raise the barrier to entry on

Our first try at a bug tracking system, several years ago, was open to
anybody to create entries, and we found that the signal-to-noise ratio
went to zero in no time.  Too many not-a-bugs, too many support
requests, too few actual bugs.  We went back to using the pgsql-bugs
mailing list.

It could be that in the intervening time, people have gotten used to bug
trackers because of their availability on other projects.  If so, we
might find a better grade of reports coming in.  I'm not very optimistic
about that though.

As for raising the barrier, you can presently submit bug reports to
pgsql-bugs by either mail or webform.  Most of the bug trackers I'm
aware of are webform-only.  I don't consider that a step forward,
especially since a webform isn't very conducive to making good reports
(it's hard to attach test cases, for instance).

			regards, tom lane

---

From: Josh Berkus <[email-masked]>
Date: Thu, 26 Feb 2004 22:10:21 -0800

Tom,

> requests, too few actual bugs.  We went back to using the pgsql-bugs

I actually sort of agree with Tom, although I don't want to raise the barrier 
too high.   I'd suggest allowing all registered users to submit bugs.   
Needing to go through registration should severely reduce the "noise", even 
if we give no restriction on who can register.

I field the Advocacy webform right now, and only get about 10 e-mails a day, 
even though some of those are really support requests better handled by the 
mailing lists.   I think we could handle 5 bad bug reports a day.

> (it's hard to attach test cases, for instance).

Both the BZ and GForge webforms allow uploading files.   And I'd far rather 
have a single copy of a test case on our web site than a couple dozen being 
e-mailed out.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: Tom Lane <[email-masked]>
Date: Fri, 27 Feb 2004 01:19:07 -0500

> too high.   I'd suggest allowing all registered users to submit bugs.

Possibly workable, but what's your definition of "registered user"?

I'd hope that anyone subscribed to any of the mailing lists would be
considered registered, for instance.  Not sure if we can do that with
either BZ or GForge; anyone know?

			regards, tom lane

---

From: Josh Berkus <[email-masked]>
Date: Thu, 26 Feb 2004 23:11:14 -0800

Tom,

> Possibly workable, but what's your definition of "registered user"?

Signing up via a webform, getting an e-mailed password back, logging in.

> either BZ or GForge; anyone know?

Usually it works the other way around; people can't subscribe until they've 
registered via web.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: Andrew Dunstan <[email-masked]>
Date: Fri, 27 Feb 2004 09:29:24 -0500

>Usually it works the other way around; people can't subscribe until they've 

I believe it should not be hard to do a one-time bulk registration of 
everyone on the lists, if that was desired.

Stepping back a bit and gathering a few threads.

BZ versions etc. There is finally some movement in the mainline BZ code 
to get DB independence into it - and the first DB to benefit will be 
Postgres.  Dave Lawrence at RedHat appears to be working again on 
landing this (after a long hiatus). See  
http://bugzilla.mozilla.org/show_bug.cgi?id=98304 and 
http://bugzilla.mozilla.org/show_bug.cgi?id=146679 . The reason I would 
prefer to go with mainline BZ (assuming we go with BZ at all) is that my 
past experience of upgrading BZ has not been pleasant, and I am sure it 
would be even harder doing it from a fork like the RedHat one.

Signal to Noise. It's not at all clear to me why a bug tracking system 
should have a worse signal to noise ratio than a mailing list with 
similar access rules, especially since we also provide the facility to 
log bugs through a web form directly off the postgresql.org home page. 
But even if it does, that can be managed by good triage. That should 
improve the ratio for all but those doing the triage. Personally, I'd be 
surprised if it took one knowledgable person more than 30 minutes a day 
to weed out the garbage (sorry for the mixed metaphor), and if the load 
was spread across several people it would be just a few minutes a day 
for any one of them, at a significant saving to everyone else.

Email interface: it should not be beyond the wit of man to provide some 
level of email interface to any reasonable bug tracking system. Whether 
or not it is worth doing depends on the demand. Two obvious places for 
it would be 1) to allow initial logging of a bug via email, and 2) 
periodically run query 'foo' and email me the results. Getting a once a 
day digest of new bug reports might be quite nice in fact.

One size fits all: I understood that this discussion arose in the 
context of a suggestion to migrate GBorg to a GForge base (a proposal I 
generally support). What is right for the core project might well not be 
right for GBorg projects. Perhaps a conservative approach might be to 
try things out on GBorg/GForge and see how things go, without touching 
how the core operates for now.

cheers

andrew

---

From: Shridhar Daithankar <[email-masked]>
Date: Fri, 27 Feb 2004 20:21:27 +0530

> everyone on the lists, if that was desired.

I agree. If possible we could also run postgresql registration system where we 
can track general usage of postgresql on various fronts, for the information 
people are willing to put their name on. It could be a massive advocacy 
ammo..

> for any one of them, at a significant saving to everyone else.

Look at KDE bugzilla. They first make you search and then file the bug. I have 
seen duplicates dropping from several thousands to few hundreds. Simple but 
effective step. For sure postgresql will hardly receive that kind of bug 
flurry.

They put a direct report a bug in KDE2.0. Click on a menu item and it send a 
bug report. As a result they had massive duplicates. Now the menu item give 
you a URL to click on, then you go and search etc. Very nice system.

> day digest of new bug reports might be quite nice in fact.

Logging bugs via email is a bad idea because you can not enforce the fields. 
Would you like somebody filing a bug via mail and leaving postgresql version 
out?

Let people use webforms. It is nice enough IMHO..

 Shridhar

---

From: Greg Stark <[email-masked]>
Date: 27 Feb 2004 09:57:24 -0500

> (it's hard to attach test cases, for instance).

There are plenty of bug tracking systems that use email extensively. In fact I
think the traditional approach was to be entirely email based. GNATS, the
venerable candidate in this field for example, is entirely email based. But
GNATS kind of sucks.

The Debian system is entirely email controllable, including command messages
to close, reassign, etc. bugs. It depends on people following instructions and
following up to the numeric address it sends you.

RT behaves like a ticketing system where it assigns you a ticket number on the
initial email and then tracks subsequent emails by the subject and other
headers.

I dislike BZ for the way it *forces* you to use the web interface. I prefer
email based systems for the simple reason that I already have a perfectly good
tool for composing text and reading conversations. It alerts me when I get
messages, sorts the messages into folders etc. The last thing I want to do is
have to remember 20 different web sites to check to see if there's any news.
And the last thing I want to do when I have a long detailed explanation of a
problem is try typing into some little bitty box in a web browser with the
pitiful editing features they have.

I also dislike BZ for aesthetic reasons. If one person is editing a ticket
while another person updates the same ticket, it refuses your edits and you
have to start all over. I think all the updates are stored in one big field.

-- 
greg

---

From: [email-masked]
Date: 27 Feb 2004 10:19:15 -0800

Hi,

please look at CodeBeamer (www.intland.com) it has all featured you
described and for selected open source projects is free now.
It is a web based collaborative software development platform with
-project tracking (dashboard)
-tracker
-document manager (sharing + versioning)
-forum
-cvs, Subversion and other SCM integration, GUI  
-code browsing, xref for C/C++ and Java
-automated build

Thanks,
Janos

---

From: Josh Berkus <[email-masked]>
Date: Fri, 27 Feb 2004 10:48:57 -0800

Folks:

ALTERNATIVE BUG TRACKERS:

Jira:   Core did look at and consider (and debate) Jira.   Atlassian are 
enthusiastic PostgreSQL supporters and offered to host Jira for us.   
However, Jira is not OSS and for various reasons it would be difficult to 
host a Jira installation at Hub.org.   We're very reluctant to endorse any 
non-OSS, externally hosted solution becuase of the distinct possibility that 
the company will have a change of management and drop us.  There is also a 
significant political issue; by adopting a non-OSS piece of infrastructure, 
we are effectively saying that OSS software isn't good enough, in the eyes of 
many members of the public.

RT:   I've been using RT for OSCON, and am not wowed by it.    Of course, I 
can say the same of BZ and GForge-Tracker.   From my perspective, it's 
neither better nor worse than the other solutions, although the interaction 
with e-mail is nice.
More importantly, *we* would have to do the port to PostgreSQL.   This is 
pretty much prohibitive; how long have we been working on an update to the 
main site, Techdocs, and/or Advocacy?    If we pick a solution which is not 
ready *right now* I fear that we will still be having this discussion in late 
2005.   I also don't see any good reason, politically, to adopt a tool by a 
community who are not at all enthusiastic about Postgres -- when there a 
those available that are.

Both of the above alternatives have 2 major issues:
1) They are each bug trackers and bug trackers only.   They do not deal with 
community or code management at all.   I would tend to prefer an integrated 
solution where one is available.

2) For whatever reason, most of our volunteer web crew seem to be PHP 
developers.   We haven't attracted many Perl or Java programmers to helping 
with the site.   This may be a chicken-and-egg thing, but unless there are 
several untapped Perl Hackers/Java programmers waiting to jump in and do 
integration work for RT, Jira, or whatever, any non-PHP solution 
automatically carries a detraction.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: Andrew Dunstan <[email-masked]>
Date: Fri, 27 Feb 2004 14:12:31 -0500

>have to start all over. I think all the updates are stored in one big field.

AFAICS it's one row per comment, at least in the 2.17 code base. BZ does 
have horrible locking issues - they are being dealt with as part of the 
bugs I referred to elsewhere.

cheers

andrew

---

From: Josh Berkus <[email-masked]>
Date: Fri, 27 Feb 2004 15:31:14 -0800

Mikhail,

> For a standalone bug/issue tracking tool take a look on 
> http://roundup.sourceforge.net

I don't see PostgreSQL support listed -- just SQLite and MySQL.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: Greg Stark <[email-masked]>
Date: 27 Feb 2004 23:04:06 -0500

Andrew Dunstan <[email-masked]> writes:

> Email interface: it should not be beyond the wit of man to provide some level
> of email interface to any reasonable bug tracking system. Whether or not it is
> worth doing depends on the demand. Two obvious places for it would be 1) to
> allow initial logging of a bug via email, and 2) periodically run query 'foo'
> and email me the results. Getting a once a day digest of new bug reports might
> be quite nice in fact.

Actually none of these are quite the most important. I think the most
important aspect of the email interface is being able to submit additional
information on a bug.

I find it frustrating to receive an email saying "user foo said foo" and not
be able to hit reply to send a response. Instead I have to start a browser,
click a link in the email, log in with a username and password, ...

If something sends me an email it should expect me to respond in the same
medium.

-- 
greg

---

From: elein <[email-masked]>
Date: Fri, 27 Feb 2004 20:14:16 -0800

There is a roundup version for postgresql. I have not tried it.
For python people, this is the ultimate solution.  It is
customizable to death. I have the mailing list archives for
the last couple of months.

I like round up and use it. It has a great email interface
and a "nosy" list feature which enables people to track
the status of their issues.

But as it is now, a resident python person would be extremely
helpful to wrap up any customization (yes we'll want customization).

--elein
[email-masked]

On Fri, Feb 27, 2004 at 03:31:14PM -0800, Josh Berkus wrote:
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org

---

From: "Greg Sabino Mullane" <[email-masked]>
Date: Sat, 28 Feb 2004 17:05:16 -0000

> 2) For whatever reason, most of our volunteer web crew seem
> to be PHP developers. We haven't attracted many Perl or Java
> programmers to helping with the site. This may be a chicken-and-egg
> thing, but unless there are several untapped Perl Hackers/Java
> programmers waiting to jump in and do integration work for RT,
> Jira, or whatever, any non-PHP solution automatically carries
> a detraction.
 
Definitely a chicken-and-egg thing. I am a Perl person, otherwise
I would have done more than I have on the site. I cannot speak
for Java, but I don't think Perl would be a problem, as I can think
of a few people besides myself with Perl skills who would be
willing to help out.
 
FWIW, I think bugzilla is our best option - it's open source,
mature, and familiar to a lot of people.
 
- --
Greg Sabino Mullane [email-masked]
PGP Key: 0x14964AC8 200402280736

---

From: Kaare Rasmussen <[email-masked]>
Date: Sun, 29 Feb 2004 02:35:59 +0100

> Why GForge?

GForge seems to be technically OK. But what about the future outlook. The home 
page lists 5 projects, whereof the 4 are tests. Are you sure they will not 
fold in a month or two, will they be reliable, responsive and real nice (the 
three r's) ?

-- 
Kaare Rasmussen            --Linux, spil,--        Tlf:        3816 2582
Kaki Data                tshirts, merchandize      Fax:        3816 2501
Howitzvej 75               Åben 12.00-18.00        Email: [email-masked]
2000 Frederiksberg        Lørdag 12.00-16.00       Web:      www.suse.dk

---

From: Tim Larson <[email-masked]>
Date: Sun, 29 Feb 2004 03:03:33 +0000

> fold in a month or two, will they be reliable, responsive and real nice (the 

http://gforge.org/ is not a hosting site, that is why you only found 4
test projects and the GForge project itself hosted on the site. The idea
is that you download the software and host it on your own hardware.

--Tim Larson

---

From: "V i s h a l Kashyap @ [Sai Hertz And Control Systems]" <[email-masked]>
Date: Sun, 29 Feb 2004 22:17:18 +0530

Dear all ,

I dont know to what state this discussion has reached but
have a thought for

http://www.otrs.org

It has Postgresql Support and uses Perl

-- 
Best Regards,
Vishal Kashyap
Director / Lead Developer,
Sai Hertz And Control Systems Pvt Ltd,
http://saihertz.rediffblogs.com
Jabber IM: [email-masked]
ICQ :      264360076
Yahoo  IM: [email-masked]
-----------------------------------------------
You yourself, as much as anybody in the entire
universe, deserve your love and affection.
- Buddha
---------------
pgsql=# select marital_status from vishals_life;

marital_status
------------------
Single not looking

1 Row(s) affected

                    ___
                   //\\\
                  ( 0_0 )
----------------o0o-----o0o---------------------

---

From: Josh Berkus <[email-masked]>
Date: Sun, 29 Feb 2004 12:11:33 -0800

Folks,

I thought that I would give everyone a summary of the current discussion of 
collaboration tools and bug-trackers for our project as I read them.   I 
think that we are quite close to a consensus.   Please comment if I've missed 
something.

GBorg-->GForge migration:  so far, nobody has objected to this idea, except 
for justifiable caution about the resources required.    If the conversion 
can be accomplished relatively seamlessly, and/or through outside help, I 
don't think we have any reason NOT to proceed with a *gradual* migration.

BugTrackers:  here, opinion is more divided.   Many people seem to feel that 
they would like bug trackers more sophisticated than those offered by the 
built-in GForge tool.    The criteria that seem to have general consensus 
are:
A. The bug tracker should have some kind of e-mail interface which allows 
responding to bugs a well as tracking them, so that people who don't like web 
interfaces don't need to use them.
B.  The bug tracker must be OSS; proprietary software is too risky when there 
are alternatives.
C. The bug tracker must use PostgreSQL, and it would be preferable if 
PostgreSQL support was available in the default branch of the project.

And I will add one that I see as unavoidable, even though it's been sort of 
glossed over in the discussions:
D. The bug tracker should not require extensive customization or other work by 
our team, becuase we simply don't have the people.

Based on this, I will evaluate the various bug trackers which have been 
mentioned to date:

GForge's Tracker:  This choice has the tremendous benefit of already being 
built-in to GForge and thus integrated with the rest of the project 
infrastructure.   On the rest of the criteria:
A. GF-Tr does not support e-mail interaction at all.
B. pass
C. pass
D. pass
Otherwise, GF-Tr's other detraction is that it is relatively unsophisticated, 
not supporting, for example, tying bugs to version numbers.  This simplicity 
can also be an asset as far as start-up time is concerned, though, but there 
exists the danger that newbies would use the tracker while developers 
continute to use e-mail. making the system ineffective.

BugZilla:  This has been a popular suggestion because lots of people are 
familiar with it.   However, BZ fails our criteria on three counts:
A.  BZ does not support issue alterations by e-mail; in fact, you can't even 
log in by e-mail link.
B. Pass
C. BZ does not have any PG support in its default branch, and the RH port is 
currently unmaintained.   While a member of the BZ team is attempting to 
complete a port, there is no expected completion date.
D. Given C., we could reasonably expect that using BZ would require 
significant support from the PG community in order to maintain a PG port.  
Given that one of the goals of the migration is to *reduce* the resources 
required by our community to maintain our infrastructure, this seems unwise.
     There is also the factor that several people on this list hate BZ's 
interface with a passion not expressed for other possible tools. I am one of 
them, I'm afraid, and since I am the primary volunteer for admining the 
system, I think my opinion carries some weight.   I find the BZ interface 
baffling, cumbersome, inefficient, and difficult to learn.

Jira:   While I have not actually tested it, this is known as a very 
sophisticated, professional enterprise-grade bug tracker.  The commercial 
developers are PostgreSQL supporters and have offered us this option as their 
support for our project, for which we are greatful.
A.  Pass
B.  Jira is unfortunately not OSS, meaning that we would be 100% dependant on 
the management policy of Alessian corp. for our use of it.   I am not 
comfortable with this idea, nor is Core, nor several other people.
C. Pass
D. Pass
There is the further issue that based on technical requirements Jira might 
have to the eternally hosted to postgresql.org, making it difficult to 
integrate it into the rest of our operations.

Request Tracker:  perl.org's issue tracker has grown quite sophisticated and 
added PostgreSQL support.
A. Pass -- RT supports commenting on, and modifying, bugs by e-mail, as well 
as running e-mail "scripts" on creation or alteration of bugs.
B. Pass
C. Pass -- PostgreSQL and MySQL are fully supported in version 3.
D. One possible reservation may be integrating RT with GForge.  Andrew D. and 
some of the GForge people will be checking on how troublesome this will be, 
and whether or not this might become a standard GForge option in the future.
       Overall, I personally am liking the new RT and seeing it as our best 
option for a bug-tracker which would genuinely improve the operations of our 
community.   One thing I'm really attracted to is the ability to create 
"personal list" so that I can put my personal core-member todo list online.

Roundup:  This was suggested by a couple of people, including Elein who is 
quite fond of it.   Per my perusing, however, there are several issues:
A.  Pass: roundup allows full interaction by e-mail.
B.  Pass
C.  Roundup was designed not to rely on a relational database.   See: http://
roundup.sourceforge.net/doc-0.6/overview.html#roundup-s-hyperdatabase
Like a lot of Zope tools, Roundup uses python objects for storage of data 
except between sessions.    Further, where Roundup does suggest databases for 
scalability, their recommendations do not include PostgreSQL.  While this is 
a perfectly valid design methodology according to certain criteria, I think 
that the PostgreSQL project would be very much sending the wrong message to 
use an effectively non-Postgres tool.
D. If there is a version of Roundup which supports PostgreSQL, it is not the 
default branch ... once again putting us in the same situation we would be in 
with BZ or are in with GBorg.

Other Tools:  The other bug tracking tools, OSS and otherwise, do not seem to 
be anywhere near as mature as the above options, making them not an 
enhancement to current issue processing.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: "Marc G. Fournier" <[email-masked]>
Date: Sun, 29 Feb 2004 16:53:01 -0400 (AST)

> A. GF-Tr does not support e-mail interaction at all.

Just curious, but:

	1. how much work would be involved in adding that?
	2. would the gforge developers be willing to integrate it in?

The reason I ask is that we have several PHP developers around, some of
which might be willing to work on integrating such into the bug tracker
... ?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: [email-masked]           Yahoo!: yscrappy              ICQ: 7615664

---

From: Neil Conway <[email-masked]>
Date: Sun, 29 Feb 2004 16:26:01 -0500

Josh Berkus wrote:
> D. One possible reservation may be integrating RT with GForge.

I'm confused. Are we considering moving core backend development over 
to GForge as well, or just GBorg? (Personally the former doesn't 
strike me as a good idea, at least initially.)

> I think that the PostgreSQL project would be very much sending the 
> wrong message to use an effectively non-Postgres tool.

Frankly, I think the PostgreSQL project would be sending "the wrong 
message" if we chose our tools on any basis other than functionality. 
We ought to use what works, whether it supports PG or not. Whether the 
bug tracker tool uses PostgreSQL, flat files or MS Access to store 
data is entirely secondary to whether it serves the needs of the 
development group.

-Neil

---

From: Josh Berkus <[email-masked]>
Date: Sun, 29 Feb 2004 13:49:06 -0800

Neil,

> data is entirely secondary to whether it serves the needs of the 

OK, then, more substantial:   I personally lack confidence in any tool that 
uses an in-memory object database to store persistent data.   I also feel 
pessimistic about our ability to extend and integrate a tool which uses 
radically different storage mechanism than the other tools we're using.  
Finally, for any of these things I forsee asking the communites involved with 
those projects for help, and it seems foolish to beg for help (as would 
probably be required of a project that does nor support PG) when there are 
people offering to help us.

THIS JUST IN:  as if we didn't have enough options, Talli of the OpenACS 
community has offered their help with using OpenACS modules for any of the 
web tasks we've discussed.   More later.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: Andrew Dunstan <[email-masked]>
Date: Sun, 29 Feb 2004 17:22:05 -0500

> strike me as a good idea, at least initially.) 

You are correct that this has (quite annoyingly) been overlooked in much 
of the discussion. Indeed, the needs of a GBorg project might well 
differ both from the core project and from other GBorg projects. ISTM 
the sensible thing right now would be to work on migrating GBorg and 
leave the core project exactly as it is. OTOH, there was considerable 
discussion a few months ago about bug tracking for the core project, and 
we have unfortunately largely repeated that discussion with similar 
results (for cheese in my_favourite_bugtrackers print "I like 
$cheese\n"; ). I think that a careful choice made for GBorg might allow 
us to progress the matter for the core project at a later stage, and the 
choice should be made with that possible suitability in mind.

> data is entirely secondary to whether it serves the needs of the 

The big issue is not going to be the bug tracker iteself, but how easy 
it is to glue it to GForge (and if it requires too much customised glue 
we really won't be making an advance at all). On those grounds alone a 
FOSS bug tracker surely is preferable, regardless of political 
considerations. Apart from the fact that its DB Schema lacks all 
referential integrity constraints - a legacy of its origin in 
you-know-what -  RT doesn't look half bad.

If we wanted to step outside the FOSS world, I don't think bug tracking 
would be the area where there might be most need, but maybe that's just 
me ;-)

cheers

andrew

---

From: "Marc G. Fournier" <[email-masked]>
Date: Sun, 29 Feb 2004 18:31:48 -0400 (AST)

> strike me as a good idea, at least initially.)

There are no plans, at this time, to move the core development stuff from
its current "format" ... this is all for gborg hosted projects at this
time ...

----

---

From: Josh Berkus <[email-masked]>
Date: Sun, 29 Feb 2004 14:37:18 -0800

Folks,

Re: moving the main project to GForge/whatever: we're not considering that at 
this time.

The way the discussion got entangled is that a few people mentioned wanting a 
better bug tracker than then one offered with GForge, and that we are 
considering using a Bug Tracker for the main project.     

If we do want an upgraded BT for the main project, it would make sense to use 
the same BT for GForge/GBorg projects.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

---

From: "Greg Sabino Mullane" <[email-masked]>
Date: Mon, 1 Mar 2004 01:41:32 -0000

> built-in GForge tool.
 
Another option, of course, is to try an enhance the current GForge tool.
Seems if we are willing to expend the effort to install, configure,
and (not to be overlooked) migrating something *from* GForge, one of
our options should be to direct that energy to enhancing what we already
have.
 
- --
Greg Sabino Mullane [email-masked]
PGP Key: 0x14964AC8 200402292041

---

From: Tom Lane <[email-masked]>
Date: Mon, 01 Mar 2004 01:21:16 -0500

Josh Berkus <[email-masked]> writes:
> currently unmaintained.

I was quite surprised to read this, and I'm sure Dave Lawrence (RH's BZ
maintainer) would be too.  As would be the thousands of people who
regularly use bugzilla.redhat.com.

If you want to reject BZ because you don't like it, fine, but please
don't allege that it's unmaintained or that we'd have to put our own
resources into maintaining it.  There *will* be BZ-on-PG running at Red
Hat for the foreseeable future.  Obviously Dave would like to get the
port folded back upstream, and it looks like that will happen
eventually, but we need not fear being alone in running BZ-on-PG
meanwhile.

			regards, tom lane

---

From: Kris Shannon <[email-masked]>
Date: Mon, 01 Mar 2004 19:23:18 +1100

>added PostgreSQL support.
...

>and whether or not this might become a standard GForge option in the future.
I have a lot of experience with configuring and customising RT and would 
be willing to help with this.
As a long time lurker on pgsql-hackers I vote for this option because 
it's something I can
actually help with... :-)

-- 
Kris Shannon <[email-masked]>

---

From: Kaare Rasmussen <[email-masked]>
Date: Mon, 1 Mar 2004 09:24:17 +0100

> http://gforge.org/ is not a hosting site, that is why you only found 4

Well that's what you get when you write messages at 2:30 AM. Should know 
better.

But on this topic, does a site based on GForge similar to Sourceforge exist ?

---

From: "Andrew Dunstan" <[email-masked]>
Date: Mon, 1 Mar 2004 05:19:21 -0500 (EST)

Tom Lane said:
>> C. BZ does not have any PG support in its default branch, and the RH
>> port is  currently unmaintained.
>

*nod*

The RH port is a few minor versions behind the mainline BZ project. I
suspect that reasonable Pg support is not too far away in the mainline
code. Dave Lawrence is in fact working actively on that, as I saw from a
flurry of email just the other day.

There seems to me to be sufficient resistance to BZ on other grounds to
make the matter moot. Personally, I have long learned to live with its
quirkiness and the klunky interface, and I don't find the lack of an email
interface an issue, but it is clear that others have much graver
objections on these and other grounds.

cheers

andrew

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 1 Mar 2004 10:09:04 -0500

> More importantly, *we* would have to do the port to PostgreSQL.   This is 

That's not true.  RT 3.2 supports PostgreSQL out of the box, and at
least one of Best Practical's customers (Afilias) requires that MySQL
not be the platform (because I'm just too worried about the current
license).  That isn't to say it's the only choice, but it does indeed
support Postgres.  Jesse Vincent has told me, also, that PostgreSQL
support is important to him.

RT is pretty flexible for managing issues, bugs, problems, &c.  I'm
not real sure it's right for this job, but it might be.  CPAN appears
to use it, for instance.

A
-- 
Andrew Sullivan  | [email-masked]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism. 
                --Brad Holland

---

From: Josh Berkus <[email-masked]>
Date: Mon, 1 Mar 2004 09:46:08 -0800

Tom,
> regularly use bugzilla.redhat.com.

My sincerest apologies to you and Dave Lawrence.  I misunderstood what I was 
being told on this list.    

A revised summary will be fortcoming tommorrow.

-- 
-Josh Berkus

______AGLIO DATABASE SOLUTIONS___________________________
                                        Josh Berkus
   Complete information technology 	[email-masked]
    and data management solutions 	(415) 565-7293
   for law firms, small businesses 	 fax 651-9224
    and non-profit organizations. 	San Francisco

---

From: Oliver Elphick <[email-masked]>
Date: Mon, 01 Mar 2004 19:12:40 +0000

> But on this topic, does a site based on GForge similar to Sourceforge

http://alioth.debian.org

(It is due to be taken down for a few hours this week while it is moved
to a new machine.)

Oliver Elphick