commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Date Tue, 20 Jan 2015 07:49:37 GMT
Hello Peter,

2015-01-20 1:05 GMT+01:00 Peter Ansell <ansell.peter@gmail.com>:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message