Rob,
<snip>
As we've discussed, the current OOo maintains the codebase, development and
release processes. It also provides a range of services in support of OOo
and its community. One thing that does seem clear (at least as the forum
and wiki are concened) is that as far as the servers running in Germany are
running on borrowed time, and to be honest that was the situation years ago
as they aren't housed in what I would regard as a data centre complying with
Sun and now Oracle enterprise standards. Oracle shouldn't tolerate this
continuance.
Thus, we need to migrate the services that we want to continue on at Apache.
We must now sentence each according to some broad strategy, which could
include options such as:
1) shutting down the service, and removing access to its content
2) shutting down the service, but provide some form of frozen archive
snapshot of content
3) rehosting the service on Apache infrastructure, but say on a Solaris
zone
4) rehosting the service on Apache infrastructure, but moving to a
preferred stack (Ubuntu VM or FreeBSD Jail).
5) migrating the content to the Apache-preferred application in this
space.
That is a good way of looking at it.
In the case of (3) and (4), we also need to decide whether the project can
continue to provide active support -- broadly to standard and resources of
the pre-Apache OOo -- or whether we switch to a sustain level of support --
that is keep the service up and running as-is but deprecate upgrades and
extensions of use.
I would think that for most services (1) and (2) are a matter of last
resort. (5) would be wonderful, but in nearly all cases, it's going to be
entirely impractical within the timescale that I suspect that Oracle will
require. So I suggest that what we will be left with is rehosting (4) in
the short term, with possible migration (5) if and when the project
resources are secured. Since Apache seems to be in the process of retiring
its Solaris infrastructure, this means that option (3) is also pretty much a
last resort only to be considered if the application is heavily Solaris
dependent.
I'm not assuming that everything gets moved over by default. That's
certainly the easiest thing for project members to think about, that
we'll just continue everything as it was before, but do it at Apache.
But was everything working well before? I'm looking now at dozens of
Kenai projects that have seen zero activity in a long, long time, or
only have spam in them. Personally I'm not interested in creating an
OpenOffice.org museum. I want a living, growing project, with no dead
wood.
There is a natural tendency to segregate the project into dozens of
little boxes and to give every box and every person a title and create
a multi-tiered bureaucracy of steering committees and leads and
deputies to manage these dozens of boxes. That is a very easy thing
to do. Too easy. But Apache is not like that. Within a project
anyone can do anything. Projects are flat. There are no boxes. If a
committer wants to patch code one day, then modify the doc another
day, translate it into French and then after dinner update the
website, they can.
I sensed that several project members, including myself, where
skeptical when this Apache project first started, and we had just a
single ooo-dev list. How could this possibly work, without a separate
marketing list, a QA list, a Doc list, a Support list, an
infrastructure list, and 145 different national language lists? We
must hurry and recreate the boxes from OpenOffice ASAP lest we
actually talk to each other as one project!
But it has worked out pretty well, I think, having a single list.
We've all learned more about how the parts of the project work, and
what our collected concerns and priorities are. I think this is a
good thing. I realize that at some point we'll need to create some
additional lists and additional wikis. But I'd urge a minimalist
approach. Create only what is needed when it is needed. Let's not
rush to recreate the 200 boxes of OpenOffice.org. I think we can do
better than that.
Obviously, this complicates the migration effort. We need to discuss
and decide which services are preserved and according to your 1-5
methods above. Luckily I think there is consensus that we must
preserve the phpBB user support forums, so maybe we start with that?
OK, so you see a lot more dead wood which would fall into (1) and (2).
If that's the case, then the project needs to reach a consensus and we
need to pass sentence explicitly rather than by default. I have
profession experience of managing large migrations, but as to this one,
I have no view other than my interests in the forums and wiki.
As we've discussed elsewhere, the OOo forums and OOo wiki can easily fall
into (4), though whether the wiki moves into sustain support is still an
issue. In this case Apache will provide a hosting service which is directly
supported by the infra team, but they will undoubtedly expect the project to
provide in VM/Jail/Zone day-to-day administration, albiet compliant with
wider operations and security standards.
The obvious question we'll get is whether our wiki content could be
migrated to confluence or moin moin, to run on existing
infrastructure. Has anyone investigated this? Saying that
translation is impossible due to X, Y and Z would be a great answer.
But saying we haven't really looked but it appears to be hard, is not
a great answer. Remember, getting MediaWiki supported at Apache will
be hard as well.
Rob, I think that I said here and elsewhere that *I* have looked at it
and it *will* be hard. I didn't say impossible. That's a slightly
different point Just look at
* http://wiki.services.openoffice.org/wiki/Special:Statistics
* http://wiki.services.openoffice.org/wiki/Special:Version
for the volumetrics and MediaWiki extensions used. If you google
"mediawiki confluence migration" then you will see that isn't a trivial
exercise even for wiki using standard MW with no extensions: it would
involve person-years of effort. I have suggested (4) rehosting but on a
sustain basis for the wiki. I can set all of this up, if agreeable to
the project. It doesn't need further material resources from the Apache
team. This would at least buy us the time to do a proper migration plan
and resource it.
Regards Terry
