Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of ansell.peter@gmail.com
 designates 209.85.213.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <m9jjbb$8pl$1@ger.gmane.org>
References: 
 <CAB917RLJE+gFEpw=yp-c-HpXEnvL12JZLLpc4wphGyjGH_6=9Q@mail.gmail.com>
	<54BD1A01.7060401@apache.org>
	<54BD3396.10001@gmail.com>
	<CACZkXPwA7NXEq+Bk_dLrfXOf3EgATDFEVuhFT_RfiqmZYkC7jg@mail.gmail.com>
	<3ecbcf0b794ba1271c8db6ebd7168af7@scarlet.be>
	<54BD43FC.2020109@gmail.com>
	<abaeebc0992cc23d79159665604bb81d@scarlet.be>
	<m9jjbb$8pl$1@ger.gmane.org>
Date: Tue, 20 Jan 2015 11:05:25 +1100
Message-ID: 
 <CAGYFOCTM3w02VA6LfmYDP5k1Zn4oetdtCf0_1beCE-OXXhEvaw@mail.gmail.com>
Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
From: Peter Ansell <ansell.peter@gmail.com>
To: Commons Developers List <dev@commons.apache.org>, joerg.schaible@gmx.de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 20 January 2015 at 05:44, J=C3=B6rg Schaible <joerg.schaible@gmx.de> wro=
te:
> Hi Gilles,
>
> Gilles wrote:
>
>> On Mon, 19 Jan 2015 10:50:52 -0700, Phil Steitz wrote:
>>> On 1/19/15 10:33 AM, Gilles wrote:
>>>> On Mon, 19 Jan 2015 12:15:42 -0500, Gary Gregory wrote:
>>>>> On Mon, Jan 19, 2015 at 11:40 AM, Phil Steitz
>>>>> <phil.steitz@gmail.com> wrote:
>>>>>
>>>>>> On 1/19/15 7:51 AM, Emmanuel Bourg wrote:
>>>>>> > Le 19/01/2015 15:32, Benedikt Ritter a =C3=A9crit :
>>>>>> >
>>>>>> >> Now the question is: do we want to make an exception for the
>>>>>> Commons RDF
>>>>>> >> project?
>>>>>> > I don't think we should make an exception. Setting up mail
>>>>>> filters isn't
>>>>>> > that difficult.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> We don't have "subprojects" or "projects" within Commons.  As Mark
>>>>>> pointed out, that is not allowed at the ASF.  If you want to have
>>>>>> a
>>>>>> separate project with separate lists, etc., then you need to go
>>>>>> TLP.
>>>>>>
>>>>>> All are welcome to join us.  This looks like an interesting
>>>>>> component that would be broadly useful.  Interesting people,
>>>>>> problems and code.  Welcome, all!
>>>>>>
>>>>>> But we are not just a groupId here.  All of our components benefit
>>>>>> from the combined eyeballs we have.  That is how it works and
>>>>>> how it
>>>>>> *has* to work according to our charter and ASF "anti-umbrella"
>>>>>> rules.
>>>>>>
>>>>>
>>>>> Well said. Commons is a project with components, RDF would be
>>>>> another
>>>>> component.
>>>>
>>>> Words without semantics...
>>>>
>>>> Looking up "apache project component" in a web search engine
>>>> turned out:
>>>>
>>>> * "HttpComponents"
>>>>   Here, the "components" are all related to "Http".  Not so in
>>>> "Commons".
>>>> * "Camel-extra"
>>>>   Herer (IIUC), the "components" all depend on a single
>>>> framework.  Not
>>>>   so in "Commons".
>>>> * Others use the term "components" to describe the "sub-units"
>>>> (for my
>>>>   lacking of a better synonym of "component"...) of the software.
>>>> Not
>>>>   so in "Commons".
>>>
>>> No.  Umbrella projects are not allowed at the ASF.
>>
>> What is the Apache definition of "umbrella project"?
>>
>> I'm understanding that the Apache policy forbids something (fine,
>> that's not the point).
>> Yet "Commons" is an umbrella (not what Apache calls an umbrella,
>> OK, since by policy that umbrella connat exist...) that groups
>> unrelated bits of code.
>>
>>> That is why
>>> Jakarta was broken up.  That is also why Hadoop is not one great big
>>> umbrella.  When sub-things get large enough, they become separate
>>> projects.  HttpComponents is actually a good example.  That used to
>>> be part of Commons.
>>
>> Is "large enough" the only criterion?  What is "large enough"?
>
> If the people caring for one component think they are better off with an =
own
> Apache community i.e. they make "their" component a TLP.
>
>>
>> Obviously, the policy forbidding some things (like a manageable
>> ML traffic) is causing problems to some would-be contributors.
>>
>> Rdf-commons would seem a "little" project (in terms of code, IIUC),
>> a fine fit for a place like "Commons"; yet they are forced out
>> because of a side issue.  A loss for them, and a loss for "Commons".
>> Does that make sense?
>
> Yes, the shared resources are part of the Apache Commons community. It wa=
s
> especially built to increase the responsibility of all committers for all
> components. Jakarta had a long history of died subprojects, because nobod=
y
> even recognized the death of it. Vfs as separate project would have been =
in
> the attic long ago. Not in commons because there are always some people w=
ho
> care enough at least to maintain it. And suddenly such a component can
> gather new activity.
>
> What do you expect from a rdf component implementing the API only? You wi=
ll
> see for the first weeks some increased activity and then it decreases. An=
d
> that's obviously a good thing for a component that offers only a stable
> contract. The devs will concentrate on their individual implementation in
> the long run.

Some initial discussion has been done on GitHub already but the rest
will be drawn out slightly by the implementation stages which will be
outside of commons.

The two reasons that I recall for bringing the issue up are that
contributors who want to follow the progress of the discussion but not
contribute don't want to commit to filtering messages and going
through the unsubscribe/subscribe process if they want to leave the
discussion temporarily (yes, if you know how its quite easy but its a
big deal for some), and the other reason was that we don't want to
push our traffic onto everyone who isn't familiar with RDF and isn't
interested in the fine technical aspects of finalising the API. There
are some general computing issues to deal with as always, particularly
given that Java-8 is so new and patterns haven't been widely
understood yet, but the vast majority will be wrangling an API to sit
on top of our respective codebases and provide interoperability. The
only way we have found to do that so far has been to use the W3C
RDF-1.1 specification as the arbiter, which should be okay, but there
is a lot of back and forth discussion about it on fine grained issues.

The tendency so far has been, since some of us are not paid
specifically to work on the relevant code, that once pull requests are
suggested, the discussion gets going for a few days and then falls
off. And eventually, once the API is stable it will fall off
altogether to almost zero. That last reason is the main reason for why
a TLP will not suit us, as TLP are encouraged to stay active and
develop new features for their libraries or get shutdown. It is also
why commons would be useful to us, but we are a little worried about
having to have users subscribe to a high-traffic mailing list to
discuss the API.

All of those concerns are dealt with by the opt-in nature of
GitHub/etc. issues/pull requests, where you can specifically watch a
given discussion; watch an entire repository for as long as necessary;
or switch from watching to just star a repository for future
reference, but not watch it, and hence not get notifications about it.

One option may be that if the process for having GitHub issues send
notifications to the mailing list is working fairly well could we have
the majority of our casual contributors watch a repository there to
interact with pull requests and the core contributors subscribe to
this mailing list. I gather that we would need to use Apache Jira for
issues instead of GitHub issues. Is it possible to watch an entire
project in Jira and get notifications about all discussion for a
period of time or is the Apache Jira setup to not send that level of
notifications (only infrequently administered Jira and I realise that
they are all setup differently so just clarifying that).

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org