Return-Path: 
 <ooo-dev-return-3569-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 88E0886C3
	for <apmail-incubator-ooo-dev-archive@minotaur.apache.org>;
 Sun, 14 Aug 2011 17:06:33 +0000 (UTC)
Received: (qmail 14423 invoked by uid 500); 14 Aug 2011 17:06:33 -0000
Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org
Received: (qmail 14175 invoked by uid 500); 14 Aug 2011 17:06:32 -0000
Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ooo-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:ooo-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:ooo-dev@incubator.apache.org>
List-Id: <ooo-dev.incubator.apache.org>
Reply-To: ooo-dev@incubator.apache.org
Delivered-To: mailing list ooo-dev@incubator.apache.org
Received: (qmail 14166 invoked by uid 99); 14 Aug 2011 17:06:32 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Aug 2011 17:06:32 +0000
X-ASF-Spam-Status: No, hits=0.7 required=5.0
	tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [205.178.146.53] (HELO omr3.networksolutionsemail.com)
 (205.178.146.53)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Aug 2011 17:06:23 +0000
Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50])
	by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id
 p7EH62Ri009293
	for <ooo-dev@incubator.apache.org>; Sun, 14 Aug 2011 13:06:02 -0400
Authentication-Results: cm-omr4 smtp.user=drew@baseanswers.com;
 auth=pass (LOGIN)
X-Authenticated-UID: drew@baseanswers.com
Received: from [174.140.78.93] ([174.140.78.93:47434] helo=[192.168.1.3])
	by cm-omr4 (envelope-from <drew@baseanswers.com>)
	(ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA
	id 57/6B-24350-A70084E4; Sun, 14 Aug 2011 13:06:02 -0400
Subject: Re: [www] Ext / Temp repository stability ( was Extensions and
 templates site down )
From: drew <drew@baseanswers.com>
To: ooo-dev@incubator.apache.org
In-Reply-To: 
 <CAP-ksogo2iR6LxufKqJh7u+LRbPotw6RhO5=Zq6qMLYS8g3aKQ@mail.gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 14 Aug 2011 13:06:10 -0400
Message-ID: <1313341570.30865.57.camel@sybil-gnome>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org

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