Peter Eisentraut wrote:
How about this one: Everything we have moved from the core to gborg so
far has been a miserable failure. The code is no longer maintained, or
maintained by three different competing groups, the documentation has
disappeared, the portability is no longer taken care of, and only the
bravest souls even dare look at the stuff. I think before you move
anything more, you need to have a strong, convincing community on the
receiving side rather than just kicking things out and hoping someone
will pick it up. Just because it can be built separately doesn't mean
everything needs to be.
I guess the key thing is that pgFoundry shouldn't be a community
distinct from the core. The same community standards need to apply
on both sides of the fence.
What has happened here echoes the experiences of the PHP project
very closely. PHP, too, thought that the core was getting too big
for efficient release coordination, and started moving extensions
to PECL, an extension library bolted on the side of PEAR.
Trouble is, nobody wants to be forced into the ghetto. The only way
to make pgFoundry work is to minimize the downside of living there.
Consider these:
- Don't move just "inessential" projects. Move absolutely
essential projects to push end-user and developer adoption.
- Have a tier of "official" projects that are actively endorsed
by and within the core distribution. Don't be afraid to pick a
favorite solution within a class (for example in replication).
- Discourage other developers from ignoring pgFoundry projects.
For the official tier, this could mean sending commit messages to
pgsql-committers, patches to pgsql-patches, and having the
discussions here. Resist the urge to start project-specific
mailing lists unless absolutely essential. Have everyone know
that the pgFoundry/core distinction only exists for release
engineering purposes, and that it can't be allowed to split
the community.
- Invest in integrating pgFoundry tools into the core distribution.
For example, official projects should have makefiles included in
the core that'd download and compile the latest compatible version.
Components as important as JDBC and some of the procedural
languages could be distributed this way.
mk
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
