openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eilers <>
Subject Re: [REVIEW] Staged Migration of OO.o domain properties (long)
Date Mon, 17 Oct 2011 12:29:34 GMT
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
especially in the area of webcontent for example.

Have a look here:

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 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 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 ( ->
> (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
> 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,
but I don't know that we prefer to
> 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
>> properties into Apache custodianship.
>> Instead of shoe-horning something on the Community Wiki, I want to rehearse
>> some ideas here:
>>      1. Basic Idea of Properties
>>      2. Stages of Property Migration
>>      3. Coping with Dependencies
>>      4. Identifying and Accounting for Migration Activity
>> The live 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 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 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.
>> 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
>> 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)
>> 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 MediaWiki services.
>> Risk management is required along with contingency planning and identification
>> of ways to mitigate risks that arise.
>> 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 []
>> Sent: Tuesday, October 11, 2011 14:46
>> To:
>> 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
>> 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
>> [ ... ]

View raw message