openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Curcuru <>
Subject Re: Migration: any plans to preserve mailing list archives?
Date Sun, 16 Oct 2011 23:06:23 GMT
On 10/13/2011 9:26 AM, Rob Weir wrote:
> On Wed, Oct 12, 2011 at 7:45 PM, Shane Curcuru<>  wrote:
>> Are there any plans to preserve archives of any existing @oo.o mailing
>> lists?  I didn't see a treatment of archives on the planning page:
>> Obviously any mailing lists hosted at Apache will use the normal
>> mail-archive.a.o system, but I was wondering if there's any plan or need for
>> somehow preserving the past archives of lists.
> As mentioned before, 333 legacy OOo lists are already archived, back
> to 2000, by Markmail.

D'oh, I should have thought of this.  For legacy content the Markmail 
archive is sufficient, although for any AOOo project content we always 
rely on ASF archives for new materials to insulate ourselves against 
third parties losing data (or changing policies, or going out of 

> But this does raise another question, as to how we move/migrate these
> lists (or whatever subset we want to preserve) to Apache.  In other
> words, what can be done to preserve the continuity of the current list
> subscribers?
> I see a few approaches, with trade-offs on effort/benefit.
> 1) We could set up equivalent lists at Apache, on the existing list
> infrastructure.  We send notifications to the legacy lists that the
> existing list will be shut down and invite them to subscribe to the
> new list address.  In some cases multiple legacy lists might be
> combined into a single Apache list.
> Pro: very easy to do
> Con: requires some manual steps from existing subscribers, to sign up
> for the new list, adjust inbox filters, etc.

+1, especially along lines of consolidating lists to be close to what 
other ASF projects have.  OOo had waaay too many lists.  We'll need more 
than any other project at the ASF, but not that many more.

> 2) We could do a variation on #1, but where we sign up existing list
> subscribers automatically.
> Pro:  Transparent from subscribers view.  Not too hard for us.
> Con: Is this permitted, given data protection laws, legacy website
> terms of use, etc.  In other words, can we legally do this?

-1, this is a known bad practice at the ASF.  In virtually all the list 
migration cases I know of, we only do #1 (and explicitly do not do #2).

> 3) Variation on #2 where we send a notification email directly to each
> list subscriber and allow them to opt-in to transferring their
> subscription
> Pro:  Little effort (but not zero effort) required for list
> subscribers, respects data privacy
> Con: A bit of work for us

This would be great.  If someone wants to do it (i.e. making the process 
for users to subscribe to the new list easily).

> 4) We do a variation on #2 or #3 but then (waving my arms here) use
> some admin kung fu with DNS records to make the mailing list look like
> it is still an email address.
> Pro:  This could make the move entirely transparent from the user's
> perspective.
> Con: More work for us.  Not sure if it is possible
> 5) Variation on #4 where instead of messing with DNS, we just have the
> Apache mailing list manager deal with addresses
> natively
> Pro: As with #4, this could make the move entirely transparent from
> the user's perspective
> Con: Can this be done list by list   Or is it an all-or-nothing thing?

#4 or #5:
-0.5  We should explicitly figure out the lists that the AOOo project 
community needs and wants, instead of inheriting previous lists.

> 6) Install the legacy OOo mailing list manager, SYMPA, at Apache and
> bring over the subscribers (and list archives?) directly.
> Pro: Transparent to users
> Con: More admin work for us, and not just a one-time migration, but
> ongoing maintenance by Apache of two email list infrastructures.

-0, and realize that the AOOo project would likely need to devote 
skilled sysadmin volunteers to running this system.

- Shane

> Any other options?
> -Rob

View raw message