commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
Date Tue, 20 Jan 2015 13:54:18 GMT
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 <britter@apache.org> wrote:
> 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



-- 
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


Mime
View raw message