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
topick 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
messagesto 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
onlyexists 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
makefilesincluded in the core that'd download and compile the latest compatible version. Components as important as
JDBCand some of the procedural languages could be distributed this way.
mk
