incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [REVIEW] Staged Migration of OO.o domain properties (long)
Date Sun, 16 Oct 2011 17:19:10 GMT
Hi Dennis,

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
> 
> [ ... ]


Mime
View raw message