incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From drew <d...@baseanswers.com>
Subject Re: [www] Ext / Temp repository stability ( was Extensions and templates site down )
Date Sun, 14 Aug 2011 17:06:10 GMT
On Sun, 2011-08-14 at 12:35 -0400, Rob Weir wrote:
> On Sun, Aug 14, 2011 at 12:15 PM, drew <drew@baseanswers.com> wrote:
> > On Sun, 2011-08-14 at 17:11 +0200, Eike Rathke wrote:
> >> Hi Rob,
> >>
> >> On Sunday, 2011-08-14 10:17:28 -0400, Rob Weir wrote:
> >>
> >> > IIRC, these extensions are 3rd party, under a variety of licenses,
> >> > including some that are not open source.  Is that correct?
> >>
> >> Yes.
> >
> > I for one agree with this expansive policy,

<snip>

> >> >
> >> > What do you think of a distributed approach like this?
> >
> > I have two quantitative questions which I would strongly wish to have
> > answered, if possible, before offering my opinion on long(ish) hosting
> > options.
> >
> > 1 - The percentage of inbound visitors coming from the application vs
> > from search engines.
> >
> > 2 - The percentage of artifacts that are stored directly on the OSUOSL
> > server vs a link to a remote site. I am working on the assumption that
> > this is a very high ratio, where a goodly number of these local files
> > are _likely_ stored only on this server. (not sure there would be anyway
> > to actually answer the last part of that sentence for sure..)
> >
> >
> >>
> >> Fine. Isn't much different from the current situation. Best if technical
> >> details could be worked out such that no code apart from the actual
> >> repository/directory URL needed to be changed.
> >

<snip>

> >
> 
> If there are "standard extensions", where we store the source in SVN,
> treat it as part of the project and release via the normal procedures,
> then I can certainly see hosting the extension on Apache servers.  But
> I don't see that happening for 3rd party extensions.
> 
> I don't think the basic situation changes based on domain names
> openoffice.org versus openoffice.apache.org.  

Yes - Nóirín's comments make that clear also, should of stayed with my
first choice. 

> If it is on Apache
> servers, controlled by the Apache project, using the Apache
> trademarks, then it is hard to say that code distribution can be done
> without following Apache rules for releases and licensing.
> 
> Aside from the licensing concern, I'd also be concerned with the
> impact of hosting commercial (non-open source) extensions on our
> status as a non-profit.
> 
> I think we have a two workable solutions:
> 
> 1) Host all of the extensions externally.  This could include
> Apache-extra.org.  We could link to such an external repository from
> our website, with a suitable disclaimer stating that this is a
> non-Apache site.
> 
> 2) Host only the description and metadata, essentially a catalog or
> directory, and require that all non-Apache owned (not in our SVN)
> extensions be hosted externally.  This could include external hosting
> at Apache-extras,org, SourceForge, Google, or whatever else the author
> prefers.
> 
> 
> Either option would obviously require some coordination and
> communications with the extension authors.  I prefer option #2.

[from out of left field]
Would members consider transferring ownership of the current repository
hosted on the OSUOSL server to a third party, perhaps created
specifically to take this over, and then working with them to create the
indirect reference site under the AOO project, filtering out
un-acceptably licensed items as a way to achieving option #2. This would
move the entire repository without needing to locate individual authors.

> 
> Another thing to consider is this:  If there is some load related
> issues here, then we should consider taking a close look at the top 5
> or so extensions and see if we can get them, or equivalent features
> into the core AOOo release.  So better than dealing with load, we can
> prevent the requests altogether by giving users what they want in the
> core release.

It's something to think on, again it depends a lot of that usage
information, IMO.

//drew


Mime
View raw message