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:[email protected]]
Sent: Tuesday, October 11, 2011 14:46
To: [email protected]
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
[ ... ]
