commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Date Mon, 19 Jan 2015 18:44:59 GMT
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 écrit :
>>>>> >
>>>>> >> 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 was 
especially built to increase the responsibility of all committers for all 
components. Jakarta had a long history of died subprojects, because nobody 
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 who 
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 will 
see for the first weeks some increased activity and then it decreases. And 
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.

- Jörg


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


Mime
View raw message