incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Extensions and Templates [was: Re: Draft IP Review Plan for OpenOffice]
Date Fri, 18 Nov 2011 17:03:26 GMT
On Fri, Nov 18, 2011 at 11:36 AM, Reizinger Zoltán <> wrote:
> 2011.11.18. 17:19 keltezéssel, Rob Weir írta:
>> On Fri, Nov 18, 2011 at 11:10 AM, Dave Fisher<>
>>  wrote:
>>> On Nov 17, 2011, at 9:53 PM, Ariel Constenla-Haile wrote:
>>>> On Thu, Nov 17, 2011 at 11:40:25AM -0800, Dave Fisher wrote:
>>>>> If this statement is rewritten for Binary releases to allow informed
>>>>> installation of a Language Pack whatever it's host, license and
>>>>> copyright might be - as long as on installation choices were clearly
>>>>> visible and the user explicitly opts in or out.
>>>>> This same IP framework could be used for Extensions and Templates - an
>>>>> area in total limbo with no volunteers active.
>>>> is down again (5:30 UTC).
>>>> Is this a problem with the host or a problem of lack of maintenance by
>>>> OOo side?
>>>> IIRC both and
>>>> are hosted by the Oregon State
>>>> University Open Source Labs, and have been working bad all year long.
>>> I've discussed this with OSUOSL sysadmin.
>>> The servers are overloaded. So much so that the Nagios alerts were
>>> constant. They turned them off. Every so often varnish acts up and the
>>> machines lock.
>>> When this happens I have been the only one who emails
>>> - they are almost always responsive during business hours in their time zone
>>> - US Pacific.
>>> Both servers are customized Drupal stacks at different versions. There
>>> were people from Oracle working on upgrades. No one has volunteered to
>>> administrate these from the project.
>>> Since these servers host extensions and templates with all types of
>>> licenses they are not candidates for migration into the ASF.
>>> What should we do?
>> We could move to an entirely different model.  Don't host extensions
>> at all.  With SourceForge, github, Google Code, etc., there is really
>> no good reason why we need to have a single entity host all of the
>> extensions.  It would be enough for us to have a browseable
>> catalog/registry of the extensions: name, description, category,
>> sreenshot, license and a URL to download.
>> It would not be hard to scrape the existing extension side to form
>> this kind of category.
> This steps if it done, left out the existing users who accustomed to find
> extensions in these sites.

The URL for the catalog would not change.  It would still be at

> You needs to contact all template and extensions creators to host their
> stuff in other sites.

Correct. And in return for this one-time effort they would then
experience much more stable hosting.

> What will happen with Oracle created, provided templates, extensions (report
> builder, wiki publisher, ), all under SGA?

If something is under SGA to Apache, then we can store it in SVN and
release it like any other project release.

As you know, every Apache release goes out as a source tarball with an
optional binary release.  This can then be downloaded via the mirrors.
 But with some technologies there are other, additional ways of
distributed code.  You might publish Java code on Maven Central.  You
might package other code for inclusion in Linux distro catalogs, etc.
These are all things that volunteers can do after a release.  I think
it would be the same here.  If we have an extension that we want to
release via the normal release procedures, we can then list it in the
extension catalog.  But it first needs to go through all of the normal
Apache release procedures.


> Zoltan
>> The license issue goes away, since there is no problem with having the
>> extension info hosted by Apache in a catalog of extensions.
>> Load is not longer an issue, since the catalog can be very cheap --
>> static HTML if we want, generated from XML.
>> I'd be willing to help with such an approach.
>> -Rob
>>> Regards,
>>> Dave
>>>> Regards
>>>> --
>>>> Ariel Constenla-Haile
>>>> La Plata, Argentina

View raw message