Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D26417564 for ; Mon, 1 Aug 2011 14:42:05 +0000 (UTC) Received: (qmail 13594 invoked by uid 500); 1 Aug 2011 14:42:05 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 13494 invoked by uid 500); 1 Aug 2011 14:42:05 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 13486 invoked by uid 99); 1 Aug 2011 14:42:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Aug 2011 14:42:04 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [94.136.40.61] (HELO mailex.mailcore.me) (94.136.40.61) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Aug 2011 14:41:56 +0000 Received: from host86-129-247-134.range86-129.btcentralplus.com ([86.129.247.134] helo=[192.168.1.69]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QntgV-00062V-QM for ooo-dev@incubator.apache.org; Mon, 01 Aug 2011 15:41:36 +0100 Message-ID: <4E36BB1E.1050404@ellisons.org.uk> Date: Mon, 01 Aug 2011 15:41:34 +0100 From: TerryE User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding) References: <008a01cc4ee7$ca79e5e0$5f6db1a0$@acm.org> <4E3476BB.8050506@gmail.com> <4E35D47F.6030308@gmail.com> <20110801081049.21190@gmx.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailcore-Auth: 8445677 X-Mailcore-Domain: 884398 X-Virus-Checked: Checked by ClamAV on apache.org 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 wrote: >> Hi Rob, >> >>> Von: Rob Weir >> ... >>>> 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é >> >> >>