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 <brit...@apache.org> wrote: > 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 -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/0000-0001-9842-9718 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
