Rob,
Can I give my understanding on this issue of "Apache" being the answer
to all Qs. Yes of course it is at one level because anything ongoing
under the Apache banner must fail under and comply with Apache rules and
procedures. However, if we ask the Q: are the Apache resources today
able to take this over seamlessly then the answer is at best mixed.
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.
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.
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.
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.
I'll pick this up in detail in the cwiki pages, but I felt that this
summary would be useful for the DL. //Terry Ellison
On 01/08/11 14:07, Rob Weir wrote:
On Mon, Aug 1, 2011 at 4:10 AM, Andre Schnabel<[email protected]> wrote:
Hi Rob,
Von: Rob Weir<[email protected]>
...
Right, OK, but again, where will this and many other ancillary
openoffice.org sites (like the forums etc.) actually live?
The goal would be to have then continue at www.openoffice.org.
...
Yes, I know about this and have contributed to this but it doesn't
really
answer my question...where do we go?
If my answer still doesn't make sense, maybe you can try restating
your question. I might be answering a different question than you are
asking.
I think, Kay is asking for the "physical" solution. Means:
- who will be the owner of the website
Apache
- who will pay for the servers and bandwith
Apache
- who will be the admin of the servers
Apache
What seems to be unclear is, if Apache foundation will host content
which is not directly under a *.apache.org domain.
Since the domain name is being transferred to Apache, openoffice.org
will in fact be an Apache domain.
It remains to be seen what is redirected and what ends up being the
"canonical' URL for the various services. But the goal is to
preserve the thousands of linked and bookmarked URL's to various OOo
website services, so nothing breaks. That's the ideal. We can
certainly do that for the top level services, e.g., Bugzilla, support
forums, downloads, etc. It is unclear right now whether we'll be able
to preserve all of the deep links to individual pages, e.g., a link to
a specific archived message in a list repository.
André
