Hello,
I have been looking at the migration of Gborg lately. It looks like the
only two active projects on that site are Slony, and pljava. Libpqxx has
recently moved to their own Trac site.
I would like to suggest the following course of action.
1. We set a read only date of 12/31/06
This means that all login capability, register capability, mailing
lists, bug tracking, cvs etc... will be shut off. It will only be up for
reference.
2. We set a shut down date of 03/31/07
This means it is down, rm -rf, whatever it takes.
Why?
Because past performance on the migration of gborg to pgfoundry has
shown that it will not be done, regardless of who volunteers or who
*thinks* they have time to do it.
So what will this really take?
1. The respective project members need to register their projects with
pgfoundry.
2. The respective project members need to migrate their tickets if they
see fit.
3. The respective members need to register the email lists they want.
4. There needs to be communication between one project at a time to
arrange a cut-over of their mailing lists. We have the ability to import
mbox files into mailman so their mail archives will be preserved.
Question: How is CVS handled on Gborg? Do they have their own repos? If
so we can just move them to pgfoundry yes?
Except for the pending screaming and yelling... is there really anything
wrong with this? To cut a few things off at the pass:
I think it is completely reasonable that we ask fellow community members
to help in their own migration as this is a gratis service. I also think
if those members were asked, they would be happy to help.
I am willing to have Devrim and Darcy help with this.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
