On Mon, Aug 1, 2011 at 10:41 AM, TerryE <[email protected]> wrote: > 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. >
Does Apache have finite server capacity? Of course. Does Apache as a non-profit invest in far more server capacity than it needs at the moment, just to have it sit around, idle? Of course not. Does Apache, as a non-profit organization have the ability to accept donations of money and/or hardware to create additional capacity when needed? Of course. So I'd recommend concentrating on what we want to do. As for admin resources, there is not a large admin staff employed by Apache. It is almost entirely volunteers. So for those resources, this is certainly an issue. > 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? > 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'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é >>> >>> >>> > >
