On Nov 18, 2011, at 8:19 AM, Rob Weir wrote: > On Fri, Nov 18, 2011 at 11:10 AM, Dave Fisher <[email protected]> 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. >>> >>> http://extensions.services.openoffice.org 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 http://extensions.services.openoffice.org and >>> http://templates.services.openoffice.org 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 [email protected] - >> 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.
author, copyright,... > > It would not be hard to scrape the existing extension side to form > this kind of category. Also, templates and language packs. > > 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. This "Plugin Catalog" XML would also be served so that AOO can consume it for extension, template, and language pack browsing in the UI. The URL of the plugin XML should be configurable in AOO. This nicely handles the institutional approved 3rd party issue. > > I'd be willing to help with such an approach. I like your plan, but there are further details like handling catalog submissions. These could be email to a special ML, but an automated approach might be better. 3rd parties may not react well to "arbitrary" delays. Regards, Dave > > > -Rob > >> Regards, >> Dave >> >> >>> >>> Regards >>> -- >>> Ariel Constenla-Haile >>> La Plata, Argentina >> >>
