Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dave2wave@comcast.net
 designates 76.96.30.80 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [www] Any Drupal guru's lurking? ( was : Ext / Temp repository
 stability ( was Extensions and templates site down ))
From: Dave Fisher <dave2wave@comcast.net>
In-Reply-To: 
 <CAP-ksoifTofFvwafJf-yKTxCZU55TEsmoMisBaFiz53SrkC0uw@mail.gmail.com>
Date: Tue, 16 Aug 2011 19:38:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <ACAF045B-1C9A-4D84-8744-A9A7EA27C655@comcast.net>
References: 
 <CAP-ksoiPzCqrs2CmSgxvCD1Pz7bFmq04Fueh-WAFBnY4No1UKg@mail.gmail.com>
 <CAA4ffp8G85LW=x9Y++awcrW6TQti2O8goGEJf=367ZH=qxqkSw@mail.gmail.com>
 <8151058839370557907@unknownmsgid>
 <CAA4ffp-+0-bh=zdvGrrkqy4TNcrv2+zUsCscmnh1PXT-=6PTsA@mail.gmail.com>
 <133e716559f67b121374d6f83d310257@tutopia.com>
 <1313324798.30865.16.camel@sybil-gnome>
 <CAP-ksoj50X_dt=30QTtoa=eEPaDcEBZ+RL1ZMgd+sc0k3w6i5Q@mail.gmail.com>
 <4E47CE41.1010306@hdsnet.hu> <1313330254.30865.31.camel@sybil-gnome>
 <CAP-ksoj50dJ7HSTUiZ5XJ4B-Sp3EK5gvTQ-TDuk9kSpUs-UboA@mail.gmail.com>
 <20110814151148.GC3585@ulungele.erack.de>
 <1313338531.30865.47.camel@sybil-gnome>
 <CAP-ksogo2iR6LxufKqJh7u+LRbPotw6RhO5=Zq6qMLYS8g3aKQ@mail.gmail.com>
 <1313341570.30865.57.camel@sybil-gnome>
 <CAP-ksohsDuw0La9LPAsa2FkjounJ-r_Cp0ddFk126LdaqpvrTA@mail.gmail.com>
 <1313345196.30865.68.camel@sybil-gnome>
 <EDCA7880-7DAF-4C46-857A-5F53E2D8A3B9@comcast.net>
 <1313347156.30865.73.camel@sybil-gnome>
 <A621C3C8-2A6B-4515-8A34-40A2EFFF418A@comcast.net>
 <1313347743.30865.75.camel@sybil-gnome> <1313517490.3804.13.camel@sybil>
 <CAP-ksoic0bHb9P4y2Oxp8gJGoZHY7NS8Meak_jsEfe2bGvCoRg@mail.gmail.com>
 <1313523822.92479.YahooMailNeo@web161428.mail.bf1.yahoo.com>
 <CAP-ksoiVwNEsOAcFH3LZ8o04B-6CgkDYvjoSPNbLEr9m4x5g2Q@mail.gmail.com>
 <1313525698.3804.26.camel@sybil>
 <CAP-ksoiaLF4aKxLsZGj9LWvrmob7pXUXJCun1j7_SXPyZV5o8Q@mail.gmail.com>
 <1313540780.19361.27.camel@sybil>
 <CAP-ksoifTofFvwafJf-yKTxCZU55TEsmoMisBaFiz53SrkC0uw@mail.gmail.com>
To: ooo-dev@incubator.apache.org


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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>=20
>>>>=20
>>>> Alright - If I may just ask a couple of question.
>>>>=20
>>>> There is a current site, not on ASF or Oracle hardware, that site =
needs
>>>> work, now then:
>>>>=20
>>>> Is there some reason why the current OSUOSL site can not be used =
going
>>>> forward?
>>>>=20
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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:
>>>=20
>>> 1) Links from Apache-controlled websites the extensions site should
>>> come with a disclaimer saying something along the lines of:
>>>=20
>>> "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"
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> [1] =
http://markmail.org/message/bmwviy2ls5qqtqev#query:+page:1+mid:bmwviy2ls5q=
qtqev+state:results
>>>=20
>>=20
>> Right - sorry for being slow on the uptake, I am like that often.
>>=20
>> Here is what I think I know:
>>=20
>> Oracle will at some point like us to remove their logo from the
>> OpenOffice.org sites, including extensions.s.oo.o.
>>=20
>> Jurgen, You and others are making progress on the git to svn =
migration.
>>=20
>> Dave is plowing along with a migration plan for, and execution of,
>> moving the main site into the Apache infrastructure.
>>=20
>> Kay looks to be ready to start moving part of the stie, project pages
>> IIRC, also.
>>=20
>> Terry has the wiki and forums up on staging servers, in the Apache
>> infrastructure.
>>=20
>> 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).
>>=20
>=20
> 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.
>=20
>> 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.
>>=20
>> 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.
>>=20
>>=20
>> So
>> - how long do you think we can go with the current arrangement?
>=20
> Only Oracle can answer that.  But that really doesn't impact the
> extensions site, since it is not on Oracle servers.
>=20
>> - 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?
>>=20
>=20
> Responsibility to me means:
>=20
> 1) If the server is hacked, who cleans it up?
>=20
> 2) If someone uploads unauthorized code (code they do not have the
> rights to) who responds to the take down notice?
>=20
> 3) If the underlying application stack require a critical security
> update, who monitors this and applies the patches?
>=20
> 4) Who monitors logs for errors, optimizes the database, does the
> backups and other routine maintenance?
>=20
> 5) Who sets the policies for what kind of extensions are allowed and
> which are not allowed?
>=20
> 6) Who decides who has what permissions on the server, from sysadmin,
> to application admin, etc.
>=20
> 7) Who removes spam from the user comments, and generally enforces the
> terms of service?
>=20
> These are the kinds of things that the PPMC, in conjunction with
> Apache Infrastructure, does for websites that we control.
>=20
> Do you know, is anyone doing something similar for the extensions web
> site?  Is OSUUSL doing this?  Or is there a vacuum now?
>=20
> 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?
>=20
> Maybe someone else has a better idea, but I can think of a few
> long-term solutions:
>=20
> 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.)
>=20
> 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.

>=20
> #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.

>=20
> 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

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