incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [www] Any Drupal guru's lurking? ( was : Ext / Temp repository stability ( was Extensions and templates site down ))
Date Wed, 17 Aug 2011 02:38:24 GMT

On Aug 16, 2011, at 6:23 PM, Rob Weir wrote:

> On Tue, Aug 16, 2011 at 8:26 PM, drew <drew@baseanswers.com> wrote:
>> On Tue, 2011-08-16 at 16:36 -0400, Rob Weir wrote:
>>> On Tue, Aug 16, 2011 at 4:14 PM, drew <drew@baseanswers.com> wrote:
>>>> On Tue, 2011-08-16 at 16:02 -0400, Rob Weir wrote:
>>>>> On Tue, Aug 16, 2011 at 3:43 PM, Joe Schaefer <joe_schaefer@yahoo.com>
wrote:
>>>>>> It just needs to be cleared by legal/board.
>>>>>> While hosting non-OSS plugins is probably out,
>>>>>> I don't see why we can't host OSS ones here
>>>>>> especially if we don't change the dns from
>>>>>> openoffice.org to apache.org.
>>>>>> 
>>>>>> We already host modules.apache.org which provides
>>>>>> a similar service for httpd modules.  One essential
>>>>>> implementation difference is that the downloads aren't
>>>>>> served by us, we just point users at the offsite
>>>>>> sources and only host metadata.  Technically that's
>>>>>> probably what I'd like to see happen to the ooo
>>>>>> extensions site as well before bringing it in house.
>>>>>> 
>>>>> 
>>>>> We had talked on another thread about a longer-term approach where we
>>>>> would host a registry of externally-hosted extensions.  That kind of
>>>>> solutions has a lot of attractive qualities.
>>>>> 
>>>>> Do you know anything about the http modules registry, e.g., where the
>>>>> code is?  That might be something we could use to jump-start an
>>>>> extensions registry.  It has the basics.
>>>> 
>>>> 
>>>> Alright - If I may just ask a couple of question.
>>>> 
>>>> There is a current site, not on ASF or Oracle hardware, that site needs
>>>> work, now then:
>>>> 
>>>> Is there some reason why the current OSUOSL site can not be used going
>>>> forward?
>>>> 
>>> 
>>> Permission wise?  If it is not on Apache Infrastructure, then it is
>>> not an Apache server, and I don't think Apache would care much.
>>> 
>>> The "gotcha" here is the trademark and the domain name.  Namely, our
>>> website points to the extension site via an openoffice.org URL
>>> (http://extensions.services.openoffice.org/) and the extension site
>>> uses the OpenOffice.org trademark.
>>> 
>>> So if we treat it like an external website, not controlled by Apache,
>>> then we need to get the trademark use into conformance with Apache
>>> policy.  The experts can correct me, but the following steps might be
>>> appropriate:
>>> 
>>> 1) Links from Apache-controlled websites the extensions site should
>>> come with a disclaimer saying something along the lines of:
>>> 
>>> "The Apache OpenOffice.org project does not officially endorse or
>>> maintain the extensions hosted at XXX.  If there are any problems with
>>> or questions about the extensions please go XXX"
>>> 
>>> 2) The PPMC, in conjunction with Apache Branding, could review and
>>> approve the use of the OpenOffice.org trademark and logo by the
>>> extension website, provided it carries a prominent disclaimer along
>>> the lines of the above.
>>> 
>>> 3)  We could redirect extensions.services.openoffice.org to the OSUOSL
>>> for a period of time, but they should start using and promoting a new
>>> URL, perhaps even a new domain name for the extensions.
>>> 
>>> Personally, I'd like to see us move to a distributed registry
>>> approach, as was discussed earlier in the thread [1].  But that does
>>> nothing to help with the immediate need for increased availability of
>>> the site.
>>> 
>>> [1] http://markmail.org/message/bmwviy2ls5qqtqev#query:+page:1+mid:bmwviy2ls5qqtqev+state:results
>>> 
>> 
>> Right - sorry for being slow on the uptake, I am like that often.
>> 
>> Here is what I think I know:
>> 
>> Oracle will at some point like us to remove their logo from the
>> OpenOffice.org sites, including extensions.s.oo.o.
>> 
>> Jurgen, You and others are making progress on the git to svn migration.
>> 
>> Dave is plowing along with a migration plan for, and execution of,
>> moving the main site into the Apache infrastructure.
>> 
>> Kay looks to be ready to start moving part of the stie, project pages
>> IIRC, also.
>> 
>> Terry has the wiki and forums up on staging servers, in the Apache
>> infrastructure.
>> 
>> The other srevices, pootle, bugxilla, eis2, etc I don't know about,
>> havent tried to keep up. (but I did read Rapheal's page on Bugzilla).
>> 
> 
> I think the above would make great material for a post on the
> project's blog, an update on the various parallel efforts we have in
> motion.
> 
>> On the extensions/templates service - I know There are millions of
>> OpenOffice.org users that link to this URL and will be for at least some
>> goodly number of months into the future.
>> 
>> It seems to me that the user facing web infrastructure is going to be
>> ready for the move fairly soon now, with code and tools sections,
>> likely, lagging a bit, but I would expect Oracle would like all the
>> stuff moved/rebranded ASAP.
>> 
>> 
>> So
>> - how long do you think we can go with the current arrangement?
> 
> Only Oracle can answer that.  But that really doesn't impact the
> extensions site, since it is not on Oracle servers.
> 
>> - and here I may be, being, slow again. It sound like you are saying
>> that on day one, after the web sites are rebranded, then this disclaomer
>> is needed at the current extensiions.s.oo.o, since it has un-savory
>> items. Am I correct on that? IF so and if the disclaimer is to say that
>> the site is not run by the PPMC, then by who (or is that whom)? Are you
>> saying that OSUUSL would be the responsible party?
>> 
> 
> Responsibility to me means:
> 
> 1) If the server is hacked, who cleans it up?
> 
> 2) If someone uploads unauthorized code (code they do not have the
> rights to) who responds to the take down notice?
> 
> 3) If the underlying application stack require a critical security
> update, who monitors this and applies the patches?
> 
> 4) Who monitors logs for errors, optimizes the database, does the
> backups and other routine maintenance?
> 
> 5) Who sets the policies for what kind of extensions are allowed and
> which are not allowed?
> 
> 6) Who decides who has what permissions on the server, from sysadmin,
> to application admin, etc.
> 
> 7) Who removes spam from the user comments, and generally enforces the
> terms of service?
> 
> These are the kinds of things that the PPMC, in conjunction with
> Apache Infrastructure, does for websites that we control.
> 
> Do you know, is anyone doing something similar for the extensions web
> site?  Is OSUUSL doing this?  Or is there a vacuum now?
> 
> This isn't a trivial task.  You might be able to get a Drupal expert
> to help restore the website to working order.  But then who maintains
> it and prevents it from falling apart in 6 more months?  Who has the
> ongoing responsibility for the website?
> 
> Maybe someone else has a better idea, but I can think of a few
> long-term solutions:
> 
> 1) Find a group of people interested in taking responsibility for the
> website in its current form (hosting the downloads, including OSS,
> freeware, shareware, trialware, etc.)
> 
> 2) Morph the existing site into something that could be hosted at
> Apache.  For example, host no files, just metadata, for the
> extensions.   Extension authors are responsible for hosting their
> downloads someplace.

There is also an OOo Kenai project with an OOo domain.

http://external.openoffice.org/

We are going to need to incorporate this, remove it, or edit it for our Apache version of
openoffice.org. This is policy to be altered somehow.

If the extensions and templates servers are hosting the actual downloads then there ought
to be a transition to either hosting by the authors or a mirror system.

If the downloads are distributed to mirrors then perhaps the current servers at extensions.services.openoffice.org
will suffice.

> 
> #2 does not need to be difficult.  It could start with an email to all
> extension authors telling them of the change and giving then some
> reasonable period, say 6 weeks, to find an alternative host for their
> downloads.  We could start with a very simple extensions website that
> builds static HTML files from the metadata (in XML), with indices for
> extensions category, license, language, etc.  Keep it simple to start.
> Build the site every hour or so.  Think like the "Planet" blog
> aggregators.  But instead of aggregating RSS/Atom feeds, we're
> aggregating "feeds" that describes an extension and generating a
> website from that.  But a website like that can handle any load, since
> the user just sees static HTML and the downloads are all distributed.

This can fit into the Apache CMS model. Initially you could setup a crontab job to republish
every so often in your people account. This would be a problem if you disappeared. I've seen
some email on infra about a project needing to access a missing person's people account in
a similar situation. Not ideal, but acceptable.

If the extension database is in xml then there is support for xslproc transforms in the Apache
CMS.

> 
> I'd be willing to help with #2.  If we have 2 or 3 people interest in
> that, I think we could get it done before the leaves change color in
> New Hampshire.

I don't think it would be hard. The hard part is getting all the authors to rehost. Perhaps
these could go onto apache-extras?

Regards,
Dave

> 
> -Rob
> 
> 
>> Thanks
>> 
>> //drew
>> 
>> 
>> 
>> 
>> 
>> 
>>> 
>>>> I just have not heard that states as such.
>>>> 
>>>> //drew
>>>> 
>>>> 
>>> 
>> 
>> 
>> 


Mime
View raw message