openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Refactoring the brand: Apache ooo + (was branding)
Date Mon, 01 Aug 2011 21:46:37 GMT
On Mon, Aug 1, 2011 at 5:22 PM, Dennis E. Hamilton
<> wrote:
> +1 to Terry's assessment.
> I favor the plan for setting up a VM and bringing over everything possible that we are
allowed to preserve and make that the new location for
> We can lock down some things that need to be continued on addresses, but the
idea is to achieve continuity and make any breakage in a gradual and tidy way.
> I don't think there is any wholesale (1-2) case and we should be very selective about
applying (2) to bits only when there is an alternative in operation and we are set up to guide
people there in a smooth way.
> It looks like (4) then some (5 backed by 2) ideally.  I see no reason to have up-front
barriers induced by wiki conversions, forum conversions, or bug-list moves.  I.e., all the
interactive provisions of the site should be preserved except where an Apache counterpart
must be used at once.  (I suppose we stop handing out e-mail addresses but
even things like registering to author public wiki pages should still work.)
> I think the key question is ensuring that we have folks to do the work and that it be
sustainable.  There are some finer-grained details, but this smells like a way to not create
some sort of wholesale disruption.

Another key question is that of accounts.  Who will have write access
to the wiki?

1) We preserve the accounts of the Oracle-hosted server and anyone who
has an account there has one at Apache?

2) We start fresh and allow anyone to sign up?

3) We hook it up to Apache's LDAP, and only allow project committers
to write to the wiki?

I think this boils down to:  is this a project wiki with project work
in it?  Or is it a community wiki?  What do we need to ensure that the
PPMC has oversight of project outputs and that our users have the
rights they think they have to those outputs, which is to say, that
new content remains under Apache 2.0?

> I see no reason to over-think this, since there appear to be ways to do a full-dress
simulation and confirmation that it works and we can keep it under wraps until we have the
go-for-launch as part of the Oracle-to-Apache transfer.  We should be looking for the *least*
that has to be done to pull this off and to shed critical path like crazy.
>  - Dennis, speaking from his armchair
> -----Original Message-----
> From: TerryE []
> Sent: Monday, August 01, 2011 09:53
> To:
> Subject: Re: Refactoring the brand: Apache ooo + (was
> 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
>> 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  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
> *
> *
> 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

View raw message