Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4E9C1FAE.8090605@bernd-eilers.net>
Date: Mon, 17 Oct 2011 14:29:34 +0200
From: Bernd Eilers <gonzo@bernd-eilers.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: [REVIEW] Staged Migration of OO.o domain properties (long)
References: <009001cc8acc$e4b6f9e0$ae24eda0$@acm.org>
 <60D46960-40A7-44B6-A24F-7569EAF58FCE@comcast.net>
In-Reply-To: <60D46960-40A7-44B6-A24F-7569EAF58FCE@comcast.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Am 16.10.2011 19:19, schrieb Dave Fisher:
> Hi Dennis,

Hi there!

The Apache OO.o migration might probably benefit from looking at the 
wiki content generated during the collabnet -> kenai Migration of 
OpenOffice.org
especially in the area of webcontent for example.

Have a look here:

http://kenai.com/projects/ooo-migration/pages/Home
http://kenai.com/projects/ooo-migration/pages/WebContentMigration


Speaking of webcontent and apache rewrite rules please notice that you 
would need an apache rewrite rule for /branding/* relative URLs in any 
project (including www)
to something like /aooo_web_projects/look/overrides/static/csi/* to 
migrate OpenOffice.org webcontent unless you do not want to modify 
almost every page.

There�s also the topic of webcontent-"decoration" with headers, footers 
and sidebar-menus and the possibilities to customize that on a per 
project basis that you should consider.
This is something covered on the 
http://kenai.com/projects/ooo-migration/pages/WebContentMigration wiki 
page for the kenai migration.


Kind regards,
Bernd Eilers.


> This is an interesting approach. In the Wikis we have accumulated many of the properties for the multitude of sub-domains for OOo. I like that this approach is open-ended and properties can be added to the parts as these make sense.
>
> The approach taken so far fits this idea. I think it makes sense to build an xml file of properties. Some properties that make sense:
>
> (1) project.
> (2) OOo subdomain.
> (3) technology (html, wiki, BZ, etc.)
> (4) Oracle resource.
> (5) AOOo svn location.
> (6) Edited or straight copy (some areas like downloads and www required editing to make the AOOo version work.)
> (7) Staging URL (downloads.openoffice.org ->  ooo-site.apache.org/downloads/)
> (8) OOo project leaders
> (9) AOOo volunteers / sysadmins.
> (10) OOo MLs
> (11) AOOo MLs (if any)
> (12) Link from Top navigation.
> (13) Rewrites of HTML resource URLs - css, branding, base urls
> (14) Apache CMS wrapping procedure - at least three approaches are needed.
> (15) AOOo branding template.
> (16) IP address / VHost (?)
> (17) LIcense.
> (18) Copyright.
> (19) Ready?
> (20) Migrated?
> (21) Apache Infra contact.
>
> I like this open-ended approach it fits current scripts in ooo-site/trunk/tools/ to handle updates from Oracle Kenai,
>
> We can use xsltprocs to generate some index pages like projects.openoffice.org.
>
> I don't know that we will want to continue with so many subdomains but the httpd server will need to know how best to rewrite URLS. We will probably always want a downloads.openoffice.org, but I don't know that we prefer udk.openoffice.org to www.openoffice.org/udk/
>
> I'll start this property file as ooo-site/trunk/lib/properties.xml - I'll define the properties in a CWiki.
>
> Regards,
> Dave
>
> On Oct 14, 2011, at 4:56 PM, Dennis E. Hamilton wrote:
>
>> I've been pondering what it takes to choreograph migration of the live
>> OpenOffice.org properties into Apache custodianship.
>>
>> Instead of shoe-horning something on the Community Wiki, I want to rehearse
>> some ideas here:
>>
>>      1. Basic Idea of OpenOffice.org Properties
>>      2. Stages of Property Migration
>>      3. Coping with Dependencies
>>      4. Identifying and Accounting for Migration Activity
>>
>>
>> 1. BASIC IDEA OF OPENOFFICE.ORG PROPERTIES
>>
>> The live OpenOffice.org wiki can be considered to be organized into separate
>> but interdependent properties (think forums vs. mailing lists vs. wikis vs.
>> downloads vs. documentation ...).  The properties even have their own
>> addresses in the roadmap for the OpenOffice.org domain.  (I owe the
>> "properties" term to Shane Curcuru.)
>>
>> Some properties provide utility services for other properties.  Also, the
>> properties are often organized on behalf of OpenOffice.org Projects.  For
>> example, there is a marketing Project in its own property that includes web
>> site, source control (for the web site), 8 mailing lists, bug tracking (the
>> general bugzilla in this case), and a download area of marketing-related
>> material.
>>
>> That's the metaphor.  It's a way to look at what there is to choreograph.
>>
>> 2. STAGES OF PROPERTY MIGRATION
>>
>> Here are five stages to consider in the migration of a property:
>>
>>   (1) Preparation - adjustments on the live property in anticipation of
>> migration including migration trials and configuration of a soft landing
>> place.  Individuals with site administration, services administration, and
>> maintenance capabilities on the existing live-site property are required.
>> Trial migration and configuration activities require Apache infrastructure and
>> AOOo project contributors on Apache-hosted systems.  There is also preparation
>> of the users of the live property for the changes to come, accounting for how
>> disruption is being avoided (or not).
>>
>>   (2) Staging - capture and packing of all live materials and movement to
>> archives and any staging area for rehosting.  The property may be dark while
>> staging happens.  Staging is a coordinated activity among live-site
>> contributors and Apache contributors.
>>
>>   (3) Re-Hosting - bringing the staged property alive under new hosting.  The
>> re-hosted property is visible either as part of the original live site (as
>> with forums and wikis, ideally) or in a new form reached independently and
>> referred from other properties of the main site (as was done with the main
>> bugzilla, for example).  Apart from any clean-up of the vacancy at the
>> OpenOffice.org site, this involves Apache infrastructure and AOOo project
>> contributors.  It is important to realize that there are software processes to
>> re-host, not just data.
>>
>>   (4) Incubation - additional adjustments and further migration effort as part
>> of incubation activity (e.g., IP review, splitting of release-facing material
>> from user-facing material, and performance tuning).  The property is
>> maintained by Apache AOOo in conjunction with Apache Infrastructure, with
>> incubation as required for an Apache/AOOo-hosted property.
>>
>>   (5) Stabilization/Continuation - ongoing operation as part of a stable
>> structure (until next time)
>>
>> 3. COPING WITH DEPENDENCIES
>>
>> Elements of the stages can overlap other stages, when there are no rigid
>> sequencing dependencies.  It may also be necessary to perform some activities
>> later in the migration than is ideal simply because there is no opportunity to
>> accomplish the activity where it is most desired.
>>
>> Also, there are dependencies and interactions with other properties,
>> especially those that are services to a particular property, or are served by
>> that property.
>>
>> There may need to be considerable triage and the users of a property will need
>> to be informed early enough that their own adjustments can be made.
>>
>> There are unknowns in terms of required effort, necessary skills, and ability
>> to adapt Apache hosting arrangements.  This is seen with the effort to migrate
>> the OpenOffice.org MediaWiki services.
>>
>> Risk management is required along with contingency planning and identification
>> of ways to mitigate risks that arise.
>>
>> 4. IDENTIFYING AND ACCOUNTING FOR MIGRATION ACTIVITY
>>
>> There may be a structure that could be placed on the wiki for identifying and
>> mapping the migration opportunities and constraints.
>>
>> I'd like to know where this is not understood before diving down to such
>> details.
>>
>> - Dennis
>>
>>
>>
>>
>> -----Original Message-----
>> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
>> Sent: Tuesday, October 11, 2011 14:46
>> To: ooo-dev@incubator.apache.org
>> Subject: RE: Status of migration of OOo domains?
>>
>> [ ... ]
>>
>> [T]here does need to be some lofting around what is a roadmap here, and
>> how does the existing live site be staged (and users informed) for transition
>> of the properties under OpenOffice.org.
>>
>> I'm thinking on it.  I am trusting that others with their hands on the knobs
>> and dials will also speak up on what they can do by way of preparation for
>> staging, and then staging.
>>
>> - Dennis
>>
>> [ ... ]