incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Preserving Legacy Content (was: Contributors versus Committers versus PMC members - AND USERS)
Date Sun, 26 Jun 2011 15:52:37 GMT

On Jun 26, 2011, at 8:38 AM, Joe Schaefer wrote:

> At this point infrastructure would be interested in
> seeing the DNS zone file for, so we
> can get some idea of how many different services
> we're talking about.
> If someone has that information, please forward it
> to me privately.  Thanks.

I was interested in the zone file, but couldn't get oracle's dns to send it to me.

Why privately? Are you preparing to do the Domain Name registration change followed by a Zone
transfer? At which point it is possible to replace services as we wish.

There is a mapping being built here:

and a little differently here


> ----- Original Message ----
>> From: Simon Phipps <>
>> To:
>> Sent: Sun, June 26, 2011 11:33:09 AM
>> Subject: Preserving Legacy Content (was: Contributors versus Committers versus 
>> PMC members - AND USERS)
>> On 26 Jun 2011, at 12:21, Rob Weir wrote:
>>> We have three basic  options for legacy content:
>>> 1) Migrate it to a dynamic  equivalent, e.g. form to forum, list to
>>> list, wiki to wiki.  This  might be using the same software or a
>>> different one, though obviously  migration is more difficult cross
>>> apps, especially in the absence of  standard formats.
>>> 2) Archive the content statically, e..g.,  wget the entire wiki, forum
>>> or list and store the static pages for  reference.  Ideally, search
>>> engines and external links don't notice  the change.
>>> 3) Ignore the legacy content and let it  disappear.
>>> I think this is a case-by-case decision that we'll  want to make, based
>>> at least partially on how how active the existing  service is.  If it
>>> gets no writes, but many reads, then #2 might be  appropriate.  If it
>>> is active with both reads and writes then that  would recommend #1.
>> I think option 2 ought to be our default for the  whole project, with all links 
>> always working. From the discussions so far, it  seems we are likely to 
>> establish new venues and modes of interaction that would  make option 1 an 
>> exception, and option 3 is always to be avoided in a community  with as long as 
>> legacy as
>> Cheers,
>> S.

View raw message