On Thu, Feb 23, 2006 at 05:33:40PM -0500, Christopher Browne wrote:
> It'll irritate them.
> 
> This is a nice way of eliminating cruft; those that ARE interested are
> free to subscribe to the new list; those that aren't can be silently
> dropped, which is probably better for all.

Call me cold-hearted, but I have absolutely no pity for anyone who can't
figure out how to unsubscribe. And I'd argue that by now they've either
setup a filter or have gone insane with the unwanted email; problem
solved in either case. :)

> >Second, by creating new lists, you'd lose the archives of everything
> >that's been discussed, which seems like it would be a huge loss.
> >  
> >
> That's a separate issue that is a good point.
> 
> Addition to the checklist:
> 
> "Draw a copy of the existing archives; if nothing else, they may be
> added, as a set of files, to pgFoundry so that old email archives are
> not lost"
> 
> Actually, taking a peek at this, "wget -r" is your friend...
> 
> The command "wget -r
> http://gborg.postgresql.org/pipermail/slony1-general/" pulls the
> archives fairly successfully in TWO forms:
> 1.  As the set of HTML files,
> 2.  As a set of "mbox-style" data.
> 
> I'll bet this is pretty easy to redeploy on pgFoundry...

Maybe, but far less easy than just moving the list over in mailman.

> >>Moving over the history of the bug tracker DB is important.  We don't  
> >>want to lose any institutional memory.  /me wonders if it could be  
> >>scripted with WWW::Mechanize....
> >>    
> >>
> >
> >I believe that a script to do that exists. I've been pushing for the
> >creation of a project on pgfoundry for the migration, so that stuff can
> >get posted and people can help.
> >  
> >
> I'm not convinced that automating bug tracker transfer is *all* that
> necessary.
> 
> We only forcibly need to bring over the items that aren't closed, and
> there are only 64 of those.  If four of us split them up, we can
> doubtless handle it in an afternoon.
> 
> And note that we'd use considerably *better* statuses; I don't think
> that an automated conversion would be all that successful

I guess maybe we just have different views of the usefulness of keeping
older info around. Of course, if there isn't a script available, then
just moving stuff over manually might well make more sense.

> >If there is such a script then I suspect we might actually be close to
> >being able to seamlessly migrate projects. There shouldn't be any issue
> >with moving mailing lists, SVN exists (and worst-case a seperate install
> >of viewcvs could be setup until there's native gforge support for SVN),
> >and I believe everything else is in the database.
> >  
> >
> Aside from "general popularity," it is not evident that we Really
> Absolutely need to migrate to SVN.
> 
> If we stay with CVS, then we could get the "bonus" that we could fairly
> much copy the files verbatim to pgFoundry, and not lose anything at all...

Oh, I thought slony was already using SVN. If not then it's an
orthogonal issue; there's a CVS to SVN migration tool that afaik will
remain supported for the indefinite future, so the move to SVN could
always be done some other time.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby at pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461