You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2015/01/19 15:32:51 UTC
[DISCUSS][RDF] Separate mailing list for Commons RDF
Hi all,
following up the discussion at [1] the folks from git github commons RDF
project [2] would like to join the Apache Commons Project, but they ask us
to create a separate mailing list for this component. Gilles has already
brought up this topic [3] and my feeling is, that we in general don't want
to create separate mailing lists for components.
Now the question is: do we want to make an exception for the Commons RDF
project?
Regards,
Benedikt
[1] http://markmail.org/message/6bdhfa3vzu6eknwl
[2] https://github.com/commons-rdf/commons-rdf
[3] http://markmail.org/message/irfkonyv47bg33ge
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Phil Steitz <ph...@gmail.com>.
On 1/19/15 11:21 AM, Gilles wrote:
> On Mon, 19 Jan 2015 18:53:35 +0100, Torsten Curdt wrote:
>>> Words without semantics...
>>
>> ...and it's still the term we are using:
>>
>> http://commons.apache.org/components.html
>
> You miss my point(s): It's totally clear what a component is,
> as defined by "Commons". The issue is how it relates to the
> "Commons project" management.
>
> Öne point is that the "Commons project" releases _independent_
> components (cf. the other post); there is no relationship
> whatsoever between the components.
They are all part of the *one* project that is Apache Commons.
>
> The principal usefulness of "Commons" is that it can be a home
> to "little" programming projects.
> But with it comes a slew of unnecessary hindrance, as felt by
> some people.
> It's just a pity that the only answer is "go TLP"...
The key point to keep in mind is the primary reason that we don't
allow umbrella projects at the ASF - insufficient oversight. The
ASF expects PMCs to provide active oversight of their project code
and communities. That means direct line-of-sight, active monitoring
by PMC members of what is going on in the project - no delegation /
abdication of oversight responsibility. This means that Commons
*must* remain one project with one PMC, or be broken up into
separate projects governed by separate PMCs. Note that that also
means that PMC members are expected to provide oversight to the
whole project, not just whatever components they happen to be
committing to at a given time.
Commons "works" because the community is willing to work together
rather than "independently." Most components would not be able to
sustain a "rule of 3" - sized community, but together we are able to
develop, review and crank lots of releases. Commons was never
intended to be a GitHub replacement for micro-communities around
individual components. That kind of thing does not work at the ASF.
Phil
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jan 19, 2015 at 1:43 PM, Gary Gregory <ga...@gmail.com>
wrote:
> I wonder how Apache DS deals with this. It's a TLP with lots of jars too.
>
Or Maven and Ant... I can't imagine there is a special ML for one 'special'
jar.
Gary
>
> Gary
>
> On Mon, Jan 19, 2015 at 1:21 PM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
>> On Mon, 19 Jan 2015 18:53:35 +0100, Torsten Curdt wrote:
>>
>>> Words without semantics...
>>>>
>>>
>>> ...and it's still the term we are using:
>>>
>>> http://commons.apache.org/components.html
>>>
>>
>> You miss my point(s): It's totally clear what a component is,
>> as defined by "Commons". The issue is how it relates to the
>> "Commons project" management.
>>
>> Öne point is that the "Commons project" releases _independent_
>> components (cf. the other post); there is no relationship
>> whatsoever between the components.
>>
>> The principal usefulness of "Commons" is that it can be a home
>> to "little" programming projects.
>> But with it comes a slew of unnecessary hindrance, as felt by
>> some people.
>> It's just a pity that the only answer is "go TLP"...
>>
>>
>> Gilles
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gary Gregory <ga...@gmail.com>.
I wonder how Apache DS deals with this. It's a TLP with lots of jars too.
Gary
On Mon, Jan 19, 2015 at 1:21 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Mon, 19 Jan 2015 18:53:35 +0100, Torsten Curdt wrote:
>
>> Words without semantics...
>>>
>>
>> ...and it's still the term we are using:
>>
>> http://commons.apache.org/components.html
>>
>
> You miss my point(s): It's totally clear what a component is,
> as defined by "Commons". The issue is how it relates to the
> "Commons project" management.
>
> Öne point is that the "Commons project" releases _independent_
> components (cf. the other post); there is no relationship
> whatsoever between the components.
>
> The principal usefulness of "Commons" is that it can be a home
> to "little" programming projects.
> But with it comes a slew of unnecessary hindrance, as felt by
> some people.
> It's just a pity that the only answer is "go TLP"...
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
>> There is the build system for some, for some it's the people - be it
>> just for oversight. And then there is the PMC and the board reports.
>
>
> Of course, there are some _administrative_ connections; it's very
> helpful to have a home for projects that by themselves wouldn't have
> the resources to handle all the management chores.
Some call it administrative connection others like to think of it as a
community.
>> Claiming there is no relationship is a very code centric point of view
>
> Of course it is; because the fundamental, crucial, central point is
> indeed that one:
Usually the ASF is know to be more than that - at least it used to be.
> IMHO, there are no more than 5 people (at any one time the real
> count is probably closer to 2) who could claim they really oversee
> the "Commons project" as a whole as would be mandated by policy.
Interesting claim...
> It's obviously not true that all the PMC members oversee the
> whole project.
...and I am wondering what "whole project" means in this context exactly.
>> - and frankly speaking a little concerning.
>
> Why?
> Everything said and done here is related, in one way or another,
> to code.
There are committers and even PMC members at the ASF that haven't even
written a single line of code.
The ASF used to have the saying "community over code".
>> I agree - commits and jira notifications can be a lot of traffic. But
>> just the dev list on it's own is so little traffic that I am having
>> trouble understanding why we are having this discussion at all.
>
> I already mentioned that "dev" was not the main problem
So we had this whole long thread just because of a surge on the
notification/commit list? Yay!
>, although
> it is understandable, and I've said it too, that some "little"
> (programming) project's contributors might want to start benefiting
> from a home at Apache without being forced to contribute to all
> the Commons (programming) projects.
Nobody is "forced to contribute" to all components (aka "Commons
(programming) projects").
> By letting them in with limited expectations[1], the community may
> grow later on, as a side-effect.
> With oversized expectations (dictated by a policy that may not be a
> perfect to a project like "Commons"), the community scares people
> away (contrary to the many times stated goal).
What "oversized expectations" are these?
The contribution to multiple components?
That's not an expectation, merely a hope.
And we want to keep the bar low for that to happen.
It has happened - often enough.
>> Why not keep the one dev list, you unsubscribe from the commits ML and
>> keep track of issues and commits through github and jira directly?
>> Could that work?
>
>
> Maybe[2] but it is _contrary_ to the policy!
Never used github?
OK, no further questions from me then.
cheers,
Torsten
[1] And _code_ quality is the one expectation on which we can't be
flexible, because if the newcomers finally go away, it is on the
rest of us that the burden will fall.
[2] I never used "github".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 19 Jan 2015 20:34:23 +0100, Torsten Curdt wrote:
>>> ...and it's still the term we are using:
>>>
>>> http://commons.apache.org/components.html
>>
>> You miss my point(s): It's totally clear what a component is,
>> as defined by "Commons". The issue is how it relates to the
>> "Commons project" management.
>
> That does not sound like "totally clear" to me. That sounds like a
> question.
>
> For whatever reason it feels like you are a bit hung up on the term.
> I merely wanted to point out that we've been using this term for a
> while now.
> ...and your query should probably also have listed that link.
It did, of course; but I wanted to find _another_ "Apache project"
where the community is quite split, code-wise.
>
> Forget the term for now. It's irrelevant for this discussion.
>
>
>> Öne point is that the "Commons project" releases _independent_
>> components (cf. the other post); there is no relationship
>> whatsoever between the components.
>
> There is the build system for some, for some it's the people - be it
> just for oversight. And then there is the PMC and the board reports.
Of course, there are some _administrative_ connections; it's very
helpful to have a home for projects that by themselves wouldn't have
the resources to handle all the management chores.
> Claiming there is no relationship is a very code centric point of
> view
Of course it is; because the fundamental, crucial, central point is
indeed that one: not everyone can (as in "is able", or "has the time",
or "is interested") work on many components.
There are more than 40 components in "Commons".
How many active contributors?
How many write code for more than 3 components?
How many vote for any one component during the release process?
IMHO, there are no more than 5 people (at any one time the real
count is probably closer to 2) who could claim they really oversee
the "Commons project" as a whole as would be mandated by policy.
It's obviously not true that all the PMC members oversee the
whole project.
> - and frankly speaking a little concerning.
Why?
Everything said and done here is related, in one way or another,
to code.
> I agree - commits and jira notifications can be a lot of traffic. But
> just the dev list on it's own is so little traffic that I am having
> trouble understanding why we are having this discussion at all.
I already mentioned that "dev" was not the main problem, although
it is understandable, and I've said it too, that some "little"
(programming) project's contributors might want to start benefiting
from a home at Apache without being forced to contribute to all
the Commons (programming) projects.
By letting them in with limited expectations[1], the community may
grow later on, as a side-effect.
With oversized expectations (dictated by a policy that may not be a
perfect to a project like "Commons"), the community scares people
away (contrary to the many times stated goal).
> Why not keep the one dev list, you unsubscribe from the commits ML
> and
> keep track of issues and commits through github and jira directly?
> Could that work?
Maybe[2] but it is _contrary_ to the policy!
Regards,
Gilles
[1] And _code_ quality is the one expectation on which we can't be
flexible, because if the newcomers finally go away, it is on the
rest of us that the burden will fall.
[2] I never used "github".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
>> ...and it's still the term we are using:
>>
>> http://commons.apache.org/components.html
>
> You miss my point(s): It's totally clear what a component is,
> as defined by "Commons". The issue is how it relates to the
> "Commons project" management.
That does not sound like "totally clear" to me. That sounds like a question.
For whatever reason it feels like you are a bit hung up on the term.
I merely wanted to point out that we've been using this term for a while now.
...and your query should probably also have listed that link.
Forget the term for now. It's irrelevant for this discussion.
> Öne point is that the "Commons project" releases _independent_
> components (cf. the other post); there is no relationship
> whatsoever between the components.
There is the build system for some, for some it's the people - be it
just for oversight. And then there is the PMC and the board reports.
Claiming there is no relationship is a very code centric point of view
- and frankly speaking a little concerning.
I agree - commits and jira notifications can be a lot of traffic. But
just the dev list on it's own is so little traffic that I am having
trouble understanding why we are having this discussion at all.
Why not keep the one dev list, you unsubscribe from the commits ML and
keep track of issues and commits through github and jira directly?
Could that work?
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 19 Jan 2015 18:53:35 +0100, Torsten Curdt wrote:
>> Words without semantics...
>
> ...and it's still the term we are using:
>
> http://commons.apache.org/components.html
You miss my point(s): It's totally clear what a component is,
as defined by "Commons". The issue is how it relates to the
"Commons project" management.
Öne point is that the "Commons project" releases _independent_
components (cf. the other post); there is no relationship
whatsoever between the components.
The principal usefulness of "Commons" is that it can be a home
to "little" programming projects.
But with it comes a slew of unnecessary hindrance, as felt by
some people.
It's just a pity that the only answer is "go TLP"...
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
> Words without semantics...
...and it's still the term we are using:
http://commons.apache.org/components.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jan 19, 2015 at 1:44 PM, Jörg Schaible <jo...@gmx.de>
wrote:
> 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
> >>>> <ph...@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.
>
Indeed, and [vfs] will soon release again; without Commons its fate would
have likely been quite different.
> 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.
>
It seems to me that Commons works pretty well. Some components are active,
other less so, some go up and down. I believe firmly that all components
benefit greatly from the oversight of the whole Commons community. Yes,
that means using one dev ML and one user ML, the simplest solution for
communication. Here, the sum is greater that the parts.
The inconvenience perceived by some by a busy ML is perhaps a reflection of
the lack of interest in Commons as a whole. In which case, if navel gazing
at one's only component of interest is a requirement, then perhaps a
different smaller, less altruistic home is best for that code and its
coders.
Gary
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
> know that for many "email list"
> == "community" == "Apache project". But Apache Commons is special. As
> pointed out - not everyone here will be involved with all Commons
> components.
Yet we consider this as one community that has cross pollination and
shared responsibilities.
> As Peter points out, it would be a short-lived activity span on a
> "Working Group" list (6-12 month) during fleshing out of the API, and
> then after say a 1.0.2 release, the list could be removed/disabled and
> traffic moved to dev@commons for general maintenance.
So bottom line: Commons is good enough for maintenance but not for development?
Please stop arguing in the line of "we don't want to annoy other
people with all our RDF discussions". We can take it. That's not the
real reason.
> That said - I believe the general points of the API design would be
> great to get inputs from other Commons developer, like the Java 8
> Streams that we are already using.
Now we are talking.
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Stian Soiland-Reyes <st...@apache.org>.
Something like https://about.gitlab.com/ installed at Apache
infrastructure would be a revolution.
Meanwhile we are stuck with mailing lists (with a subscription and
archive interface from 1995) - can we not just tweak that capability
by at least having a separate list? I know that for many "email list"
== "community" == "Apache project". But Apache Commons is special. As
pointed out - not everyone here will be involved with all Commons
components.
As Peter points out, it would be a short-lived activity span on a
"Working Group" list (6-12 month) during fleshing out of the API, and
then after say a 1.0.2 release, the list could be removed/disabled and
traffic moved to dev@commons for general maintenance.
That said - I believe the general points of the API design would be
great to get inputs from other Commons developer, like the Java 8
Streams that we are already using. I assume the committers of
commons-rdf would also be on dev@commons (e.g. for voting) - and
perhaps rdf@commons would copy to dev@commons?
On 20 January 2015 at 07:49, Benedikt Ritter <br...@apache.org> wrote:
> Hello Peter,
>
> 2015-01-20 1:05 GMT+01:00 Peter Ansell <an...@gmail.com>:
>
>> On 20 January 2015 at 05:44, Jörg Schaible <jo...@gmx.de> wrote:
>> > 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
>> >>>>> <ph...@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.
>>
>> 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.
>>
>
> We don't have a problem with the RDF traffic. That's just the way things
> work here. I understand your worries about potential contributors who might
> be put off by communication via mailing lists. To me mailing lists feel
> dated. That's why I brought up this discussion [1] on
> dev@community.apache.org. HyperKitty may be an alternative (see
> https://lists.stg.fedoraproject.org/archives/ for a demo) but it is not yet
> available.
>
>
>>
>> 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).
>>
>
> We already work this way with some of our github contributors. We have a
> standard template for README.md and CONTRIBUTING.md that should give github
> contributors all the necessary information they need. See for example the
> lang github mirror [2].
>
> Regards,
> Benedikt
>
> [1] http://markmail.org/message/exxaqmo4hsxa2d3x
> [2] http://github.com/apache/commons-lang
>
>
>>
>> Cheers,
>>
>> Peter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Benedikt Ritter <br...@apache.org>.
Hello Peter,
2015-01-20 1:05 GMT+01:00 Peter Ansell <an...@gmail.com>:
> On 20 January 2015 at 05:44, Jörg Schaible <jo...@gmx.de> wrote:
> > 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
> >>>>> <ph...@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.
>
> 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.
>
We don't have a problem with the RDF traffic. That's just the way things
work here. I understand your worries about potential contributors who might
be put off by communication via mailing lists. To me mailing lists feel
dated. That's why I brought up this discussion [1] on
dev@community.apache.org. HyperKitty may be an alternative (see
https://lists.stg.fedoraproject.org/archives/ for a demo) but it is not yet
available.
>
> 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).
>
We already work this way with some of our github contributors. We have a
standard template for README.md and CONTRIBUTING.md that should give github
contributors all the necessary information they need. See for example the
lang github mirror [2].
Regards,
Benedikt
[1] http://markmail.org/message/exxaqmo4hsxa2d3x
[2] http://github.com/apache/commons-lang
>
> Cheers,
>
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
On Tue, Jan 20, 2015 at 3:08 PM, Mark Thomas <ma...@apache.org> wrote:
> On 20/01/2015 13:07, Andy Seaborne wrote:
>> On 20/01/15 08:49, Mark Thomas wrote:
>>> At this point it looks to me like the incubator would be a much better
>>> destination, particularly given the general impression I get of the RDF
>>> community not really understanding how the ASF works.
>>
>> I am disappointed by that comment. There are several ASF projects in
>> the RDF space. They have been through the incubator. Please do talk to
>> those projects if you have concerns.
>
> My comment was overly broad. I apologise.
Oh - I misread. Mark was talking about the "RDF community".
Sorry, I only meant how the potential "Commons RDF" community
presented itself here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
> As I see it, the Apache Commons has one partcular way of working. Every
> Apache project has its own unique ways of working within the Apache way.
>From my ASF experience (and that's shockingly 12+ years now) the
"implementation" of Apache way is not that very different across
projects. It varies - but not that much. Especially in the culture. At
least it doesn't feel like Commons is "the odd one out" here just
because the code bases of the components have little technical overlap
or connection. Granted - the sandbox and the recent access rights
change is uncommon. But I think so far we managed well not to become
the next Jakarta.
> I think we are also touching on scaling Apache Commons - some the issues are
> a reflected in scaling the incubator.
>
> Torsten -- interesting that graduation could be to "commons" - has that
> happened before?
Yes, I remember at least once:
http://incubator.apache.org/projects/sanselan.html
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Benedikt Ritter <br...@apache.org>.
2015-01-20 16:09 GMT+01:00 Sergio Fernández <wi...@apache.org>:
> Hi,
>
> On 20/01/15 15:41, Andy Seaborne wrote:
>
>> Torsten -- interesting that graduation could be to "commons" - has that
>> happened before?
>>
>
> It already happened, yes:
>
> http://markmail.org/search/?q=list%3Aorg.apache.incubator.
> general+vote+graduate+subproject+commons
>
> I would like to see Apache Commons consider naming matters and
>> trademark-like issues. Stamping "RDF" across everything would not fly
>> as a TLP name because of external use and, even if in the letter it is
>> possible here, I see it as not in the spirit of avoiding confusion for
>> users.
>>
>
> Actually that could be a very good solution: we move to incubator where as
> Podling we can have more freedom for the initial design and development,
> and then I'm pretty sure we'll fairly accommodate to Apache Common in its
> current setup.
>
> Would that also work for the Commons PMC?
Sounds like a good solution to me.
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Sergio Fernández <wi...@apache.org>.
Hi,
On 20/01/15 15:41, Andy Seaborne wrote:
> Torsten -- interesting that graduation could be to "commons" - has that
> happened before?
It already happened, yes:
http://markmail.org/search/?q=list%3Aorg.apache.incubator.general+vote+graduate+subproject+commons
> I would like to see Apache Commons consider naming matters and
> trademark-like issues. Stamping "RDF" across everything would not fly
> as a TLP name because of external use and, even if in the letter it is
> possible here, I see it as not in the spirit of avoiding confusion for
> users.
Actually that could be a very good solution: we move to incubator where
as Podling we can have more freedom for the initial design and
development, and then I'm pretty sure we'll fairly accommodate to Apache
Common in its current setup.
Would that also work for the Commons PMC?
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Andy Seaborne <an...@apache.org>.
On 20/01/15 14:08, Mark Thomas wrote:
> On 20/01/2015 13:07, Andy Seaborne wrote:
>> On 20/01/15 08:49, Mark Thomas wrote:
>>> At this point it looks to me like the incubator would be a much better
>>> destination, particularly given the general impression I get of the RDF
>>> community not really understanding how the ASF works.
>>
>> I am disappointed by that comment. There are several ASF projects in
>> the RDF space. They have been through the incubator. Please do talk to
>> those projects if you have concerns.
>
> My comment was overly broad. I apologise.
Thank you.
>
> My concerns regarding understanding how the ASF works is limited to the
> sub-set of the RDF community that is currently suggesting the creation
> of the Apache Commons RDF component. If that subset overlaps with
> existing Apache projects then there might be a concern but that would
> depend on how big the overlap is (I haven't looked).
As I see it, the Apache Commons has one partcular way of working. Every
Apache project has its own unique ways of working within the Apache way.
The talking at cross-purposes is that I look from the POV of the
commons-rdf community (as I see it) and you from Apache Commons starting
point.
So what we are exploring is what the implications of that are for the
commons-rdf community and hence whether it is the best for that
community. I think we are also touching on scaling Apache Commons -
some the issues are a reflected in scaling the incubator.
Torsten -- interesting that graduation could be to "commons" - has that
happened before?
I would like to see Apache Commons consider naming matters and
trademark-like issues. Stamping "RDF" across everything would not fly
as a TLP name because of external use and, even if in the letter it is
possible here, I see it as not in the spirit of avoiding confusion for
users.
Andy
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Mark Thomas <ma...@apache.org>.
On 20/01/2015 13:07, Andy Seaborne wrote:
> On 20/01/15 08:49, Mark Thomas wrote:
>> At this point it looks to me like the incubator would be a much better
>> destination, particularly given the general impression I get of the RDF
>> community not really understanding how the ASF works.
>
> I am disappointed by that comment. There are several ASF projects in
> the RDF space. They have been through the incubator. Please do talk to
> those projects if you have concerns.
My comment was overly broad. I apologise.
My concerns regarding understanding how the ASF works is limited to the
sub-set of the RDF community that is currently suggesting the creation
of the Apache Commons RDF component. If that subset overlaps with
existing Apache projects then there might be a concern but that would
depend on how big the overlap is (I haven't looked).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Stian Soiland-Reyes <st...@apache.org>.
It might be my fault for misrepresenting "The Commons-RDF community" -
personally I am fairly fresh to the Apache (Oct 2014). The other, core
committers involved in Commons-RDF are seasoned Apache folks. I've
just tried to be a mediator.. My fault.
I think the community around commons-rdf is already strong and diverse
- if small.
How to smoothly transition that community into dev@commons is the
challenge. themselves with dev@commons.
I don't think the existing dev@commons community would have any
problem with the RDF activity - several have welcomed it and shown
interest in helping out.
But what about the other way around? It is the existing (partially
non-Apache) community that we need feedback from to shape the API -
but which several are worried would be scared about being thrown right
into dev@commons, which I hope you can see is a different, bigger
community than that of a "regular" TLP - given the small size of the
project.
I don't believe the "core committers" would have any problems with
dev@commons - the problem is the bigger community (the users@rdf in a
way) which we need to help shape what the API should and shouldn't do.
On 20 January 2015 at 14:17, Torsten Curdt <tc...@vafer.org> wrote:
>> Agree that maybe the the Incubator with a projected path to the
>> Commons could be a workable middle ground while Commons-RDF is still
>> "incubating" code-wise (but not community or Apache Way-wise).
>
> To me it comes across as if community/ASF wise is the more important
> part. This is really not meant as an offense, but if you re-read this
> thread you will see that the community part hasn't been going so well
> yet.
>
> cheers,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
> Agree that maybe the the Incubator with a projected path to the
> Commons could be a workable middle ground while Commons-RDF is still
> "incubating" code-wise (but not community or Apache Way-wise).
To me it comes across as if community/ASF wise is the more important
part. This is really not meant as an offense, but if you re-read this
thread you will see that the community part hasn't been going so well
yet.
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Stian Soiland-Reyes <st...@apache.org>.
Agree that maybe the the Incubator with a projected path to the
Commons could be a workable middle ground while Commons-RDF is still
"incubating" code-wise (but not community or Apache Way-wise).
No earlier project has gone through this route
(https://incubator.apache.org/projects/ ) - this would reuse the
deprecated "Champion" project to be Apache Commons instead of
Incubator PMC in this case.
Such a proposal has some good features - I presume commons-rdf
releases would still be voted over (and thus involve) the Commons PMC
and dev@commons (as they would after "graduating").
As an API, then Commons-RDF should not be considered stable while
being in 0.x.x-incubating anyway.
On 20 January 2015 at 13:58, Torsten Curdt <tc...@vafer.org> wrote:
>> There are several ASF projects in the
>> RDF space. They have been through the incubator. Please do talk to those
>> projects if you have concerns.
>
> I am sorry - but how are those projects relevant in this case?
>
> And what's so bad about the incubator? You could (maybe) later on come
> to Commons.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Sergio Fernández <wi...@apache.org>.
On 20/01/15 17:59, Reto Gmür wrote:
> On Tue, Jan 20, 2015 at 2:58 PM, Torsten Curdt <tc...@vafer.org> wrote:
>> And what's so bad about the incubator? You could (maybe) later on come
>> to Commons.
>
> That's exactly what clerezza did, we incubated 2009 and now propose a
> generalized version of our RDF API as Apache commons.
Can you please reply to this thread taking into account the other thread
where we actually discuss the Commons RDF approach? Thanks.
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Reto Gmür <re...@apache.org>.
On Tue, Jan 20, 2015 at 2:58 PM, Torsten Curdt <tc...@vafer.org> wrote:
> > There are several ASF projects in the
> > RDF space. They have been through the incubator. Please do talk to
> those
> > projects if you have concerns.
>
> I am sorry - but how are those projects relevant in this case?
>
> And what's so bad about the incubator? You could (maybe) later on come
> to Commons.
>
That's exactly what clerezza did, we incubated 2009 and now propose a
generalized version of our RDF API as Apache commons.
Cheers,
Reto
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
> There are several ASF projects in the
> RDF space. They have been through the incubator. Please do talk to those
> projects if you have concerns.
I am sorry - but how are those projects relevant in this case?
And what's so bad about the incubator? You could (maybe) later on come
to Commons.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Andy Seaborne <an...@apache.org>.
On 20/01/15 08:49, Mark Thomas wrote:
> At this point it looks to me like the incubator would be a much better
> destination, particularly given the general impression I get of the RDF
> community not really understanding how the ASF works.
I am disappointed by that comment. There are several ASF projects in
the RDF space. They have been through the incubator. Please do talk to
those projects if you have concerns.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
> Members of the Commons community are expected to be subscribed to the
> dev mailing list. The impression I get from reading these messages is
> that the RDF community has little to no interest in interacting with the
> Commons community.
>
> At this point it looks to me like the incubator would be a much better
> destination, particularly given the general impression I get of the RDF
> community not really understanding how the ASF works.
I don't want to sound unwelcoming - but right now I get the very same
impression.
Maybe you guys should start in the incubator and when you have reached
a certain state we can talk again.
The Incubator to Commons path is possible, too.
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Mark Thomas <ma...@apache.org>.
On 20/01/2015 00:05, Peter Ansell wrote:
> 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.
Utter nonsense. The board has never, ever forced a community to move the
attic due to a failure to develop new features. Whether or not to
develop a new feature and how to develop of are decisions for the PMC
and the PMC only and the board has never even started going down that line.
The board understands that some projects reach a state of maturity where
the majority of activity is on the users mailing list with the odd bug
report and occasionally a release. As long as there is a community
around the project answering those questions and able to do a release if
required the board will happily leave a TLP to get on with things. If
the community withers away, no-one answers user questions, no-one fixes
bug reports and there are not enough active PMC members to do a release
then the board start asking questions of the remaining community about
how to reboot it. If that fails then eventually the TLP will end up in
the attic.
> It is also why commons would be useful to us,
I am concerned at this point that the RDF community is attempting to use
the Commons TLP as a means of bypassing what they see as overly
burdensome ASF processes. I can understand that. Way back when Tomcat
was part of Jakarta I was in no rush for Tomcat to become a TLP because
of the perceived overhead. In reality, there was a little overhead for
the transition but on an ongoing basis one report to the board every 3
months barely registers.
> but we are a little worried about
> having to have users subscribe to a high-traffic mailing list to
> discuss the API.
Members of the Commons community are expected to be subscribed to the
dev mailing list. The impression I get from reading these messages is
that the RDF community has little to no interest in interacting with the
Commons community.
At this point it looks to me like the incubator would be a much better
destination, particularly given the general impression I get of the RDF
community not really understanding how the ASF works.
> 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.
ASF communities are opt-in as well. You subscribe to the dev list.
> 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.
Project development is meant to happen on the dev list. By all means use
Github to attract new contributors but the aim should be to get them
onto the dev 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).
ASF Jira projects are configured to send all updates for a project to a
single list. Some projects send this to dev@, some to issues@.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Jörg Schaible <jo...@swisspost.com>.
Hi Peter,
Peter Ansell wrote:
> On 20 January 2015 at 05:44, Jörg Schaible <jo...@gmx.de> wrote:
[snip]
>> 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.
>
> 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),
Sorry, but that sounds to me a bit like "Wash me, but do not make me wet!"
> 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.
And how should then the other ~200 potential committers of Commons (like me)
get interested and drawn in? Or take care, that a release fulfills the
Apache requirements?
> 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.
OK, but this implies that one of those 200 Commons committers above is
interested enough to create a maintenance release nevertheless in case of a
problem. Or can you be absolutely sure, that you're still around in - let's
say 5 years? The community will.
> 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.
It's about joining a (caring) community. And this is different to Github.
[snip]
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Peter Ansell <an...@gmail.com>.
On 20 January 2015 at 05:44, Jörg Schaible <jo...@gmx.de> wrote:
> 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
>>>>> <ph...@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.
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
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Jörg Schaible <jo...@gmx.de>.
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
>>>> <ph...@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
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gilles <gi...@harfang.homelinux.org>.
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
>>> <ph...@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"?
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?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Phil Steitz <ph...@gmail.com>.
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
>> <ph...@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. 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.
Phil
>
>
> Gilles
>
>> Gary
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 19 Jan 2015 12:15:42 -0500, Gary Gregory wrote:
> On Mon, Jan 19, 2015 at 11:40 AM, Phil Steitz <ph...@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".
Gilles
> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jan 19, 2015 at 11:40 AM, Phil Steitz <ph...@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.
Gary
>
> Phil
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 19 Jan 2015 09:40:54 -0700, Phil Steitz 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.
Are there other Apache "projects" that, similarly to what happens
in the "Commons project", release several completely independent
codebases?
I always saw the Commons project as something like the umbrellla
for grouping unrelated "projects" (as in "programing project") that
wouldn't otherwise reach some "crticial mass" to warrant a full-blown
project.
Gilles
> 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.
>
> Phil
>>
>> Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Phil Steitz <ph...@gmail.com>.
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.
Phil
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Emmanuel Bourg <eb...@apache.org>.
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.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Torsten Curdt <tc...@vafer.org>.
> But there will me much more in terms of discussion. That's why a TLP does make any
> sense for me.
TLP just because of a noisy API discussion - that's just not how it works.
I don't mind reading that discussion, or just deleting it, or creating a filter.
> I've subscribed to
> dev@commons.a.o in our first attempt to join the project (July 2014), and I
> have to admit the single list is a bit difficult for following some
> discussion;
Every non-ancient email client supports threading.
How can this be a problem?
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Mark Thomas <ma...@apache.org>.
On 20/01/2015 09:29, Sergio Fernández wrote:
> Hi all,
>
> I've been reading the different threads where this issue has been
> discussed.
>
> First, I'd like to say from Commons RDF we do not want to open the
> discussion of sub-project. We all are quite experienced at the ASF to
> know how bad that could be. And we are happy to be a regular component.
> In fact, if we do the things well and we come up with a agreed and
> useful API, in terms of code there will not so much activity for that
> component. But there will me much more in terms of discussion. That's
> why a TLP does make any sense for me.
>
> Asking a dedicated mailing list we simply wanted a less noisy channel of
> communication, from form RDF to All, and from All to RDF. I've
> subscribed to dev@commons.a.o in our first attempt to join the project
> (July 2014), and I have to admit the single list is a bit difficult for
> following some discussion; not about those components where I already
> have a filter on my mail client and I follow, but for those where an
> interesting topics jumps in from time to time. And many other new people
> could have
>
> Even though, I understand the positions against separated mailing lists.
> So I propose to carry an experiment during the journey through sandbox
> of the RDF component:
>
> * create a new dev-rdf@commons.a.o mailing list
> * all posts will be distributed to dev@commons.a.o with the [RDF] prefix
> * Reply-To header will be always set to the original mailing list
>
> We still need to ask INFRA if such setup would be even possible... but I
> think is worth to give it a try. What do you think? Could that work?
With my commons PMC member hat on:
-1. This is not joining the Commons community, this is bypassing it.
With my infra hat on:
We have no lists set up like this at the moment. It would be extra
effort to set this up. Given the community concerns raised, infra is
unlikely to embark down this path until those concerns are resolved.
Mark
>
> Thanks for all the constructive discussions.
>
> Cheers,
>
> On 19/01/15 15:32, Benedikt Ritter wrote:
>> Hi all,
>>
>> following up the discussion at [1] the folks from git github commons RDF
>> project [2] would like to join the Apache Commons Project, but they
>> ask us
>> to create a separate mailing list for this component. Gilles has already
>> brought up this topic [3] and my feeling is, that we in general don't
>> want
>> to create separate mailing lists for components.
>> Now the question is: do we want to make an exception for the Commons RDF
>> project?
>>
>> Regards,
>> Benedikt
>>
>> [1] http://markmail.org/message/6bdhfa3vzu6eknwl
>> [2] https://github.com/commons-rdf/commons-rdf
>> [3] http://markmail.org/message/irfkonyv47bg33ge
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi all,
I've been reading the different threads where this issue has been discussed.
First, I'd like to say from Commons RDF we do not want to open the
discussion of sub-project. We all are quite experienced at the ASF to
know how bad that could be. And we are happy to be a regular component.
In fact, if we do the things well and we come up with a agreed and
useful API, in terms of code there will not so much activity for that
component. But there will me much more in terms of discussion. That's
why a TLP does make any sense for me.
Asking a dedicated mailing list we simply wanted a less noisy channel of
communication, from form RDF to All, and from All to RDF. I've
subscribed to dev@commons.a.o in our first attempt to join the project
(July 2014), and I have to admit the single list is a bit difficult for
following some discussion; not about those components where I already
have a filter on my mail client and I follow, but for those where an
interesting topics jumps in from time to time. And many other new people
could have
Even though, I understand the positions against separated mailing lists.
So I propose to carry an experiment during the journey through sandbox
of the RDF component:
* create a new dev-rdf@commons.a.o mailing list
* all posts will be distributed to dev@commons.a.o with the [RDF] prefix
* Reply-To header will be always set to the original mailing list
We still need to ask INFRA if such setup would be even possible... but I
think is worth to give it a try. What do you think? Could that work?
Thanks for all the constructive discussions.
Cheers,
On 19/01/15 15:32, Benedikt Ritter wrote:
> Hi all,
>
> following up the discussion at [1] the folks from git github commons RDF
> project [2] would like to join the Apache Commons Project, but they ask us
> to create a separate mailing list for this component. Gilles has already
> brought up this topic [3] and my feeling is, that we in general don't want
> to create separate mailing lists for components.
> Now the question is: do we want to make an exception for the Commons RDF
> project?
>
> Regards,
> Benedikt
>
> [1] http://markmail.org/message/6bdhfa3vzu6eknwl
> [2] https://github.com/commons-rdf/commons-rdf
> [3] http://markmail.org/message/irfkonyv47bg33ge
>
--
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org