Hello Peter, 2015-01-20 1:05 GMT+01:00 Peter Ansell <ansell.pe...@gmail.com>:
> On 20 January 2015 at 05:44, Jörg Schaible <joerg.schai...@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.ste...@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 d...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
