Collaboration Tool Proposal
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
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.
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.
Joseph,
Thanks for feedback.
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.
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?
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.
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
On Thu, 2004-02-26 at 13:19, Josh Berkus wrote:
What does the Apache project run?
Not sure. Anyone?
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
Robert,
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?
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
On Thu, Feb 26, 2004 at 10:49:46AM -0800, Josh Berkus wrote:
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.
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
Jeroen,
I for one am willing to try this in the near term.
Great!
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?
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.
If it takes some scripting and/or programming to do some of this, I'm
willing to help insofar as I have time.
Terrific!
--
-Josh Berkus
Aglio Database Solutions
San Francisco
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.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.
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
Show quoted text
---------------------------(end of
broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Josh Berkus wrote:
PROPOSAL: GBorg --> GForge Migration
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.
On Thu, Feb 26, 2004 at 09:16:38PM +0100, Peter Eisentraut wrote:
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.
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
Peter,
So yes, I
think this is a reasonable plan, just don't expect "collaboration" to
suddenly appear out of nowhere.
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
Josh Berkus wrote:
Peter,
So yes, I
think this is a reasonable plan, just don't expect "collaboration" to
suddenly appear out of nowhere.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.
Perhaps when BZ supports PG - some progress is being made on that front,
but it's not a done deal yet.
cheers
andrew
On Feb 26, 2004, at 6:12 PM, Josh Berkus wrote:
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.
+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.
Why GForge?
GForge runs on PostgreSQL and their team are enthusiastic PG
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.
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.
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
On Thu, 2004-02-26 at 15:41, Andrew Dunstan wrote:
Josh Berkus wrote:
Peter,
So yes, I
think this is a reasonable plan, just don't expect "collaboration" to
suddenly appear out of nowhere.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.Perhaps when BZ supports PG - some progress is being made on that front,
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
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
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.
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
pgsql-advocacy@postgresql.org (no cross-posts).
Otherwise, let us sleep well and make dreams of a better world.
Cheers,
Jean-Michel Pouré
Robert Treat <xzilla@users.sourceforge.net> writes:
On Thu, 2004-02-26 at 15:41, Andrew Dunstan wrote:
Perhaps when BZ supports PG - some progress is being made on that front,
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.
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
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?
Peter Eisentraut <peter_e@gmx.net> writes:
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?
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
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
On Feb 26, 2004, at 11:11 PM, Jean-Michel POURE wrote:
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".
Hello,
It could be true. Perhaps a beginner's guide will do the trick.
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?
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
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
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
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.)
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.
If you would like to answer, maybe try posting to
pgsql-advocacy@postgresql.org (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';
