On 10/13/2011 9:26 AM, Rob Weir wrote:
On Wed, Oct 12, 2011 at 7:45 PM, Shane Curcuru<[email protected]> 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:
https://cwiki.apache.org/confluence/display/OOOUSERS/Mailing+lists
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
business...)
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 openoffice.org 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 openoffice.org 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
