Collaboration Tool Proposal - Mailing list pgsql-www

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