You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2015/01/16 01:47:19 UTC
[ALL] Too much traffic on the "dev" ML
Hi.
In the discussion that started about RDF, it seems that the
traffic volume is a stumbling block.
[For some time now, it has been a growing nuisance, and the
usual dismissal about filters won't change the fact: Setting
up a filter that will redirect stuff to /dev/null is a waste
of bandwidth.]
If different ML are created, people interested in everything
can subscribe _once_, and nothing will change for them.
For people who spend a lot of time just deleting dozens messages
and notifications a day, it will be a relief.
Maintaining community conversation is not a problem: just
create an "all-dev@commons.apache.org" ML for things that
need input form a larger audience (like votes).
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by sebb <se...@gmail.com>.
On 16 January 2015 at 11:21, sebb <se...@gmail.com> wrote:
> On 16 January 2015 at 11:16, Emmanuel Bourg <eb...@apache.org> wrote:
>> Le 16/01/2015 12:03, sebb a écrit :
>>
>>> Commits already have a separate list.
>>
>> Ah thanks, I thought they were merged. Maybe we could move the Wiki
>> notifications to the commits or notification lists, as well as the
>> jenkins/continuum/gump messages.
>
> There are very few Wiki or Gump messages.
>
> I agree it might make sense to have CI messages go to the commit list,
> as it is the commits that affect the test runs, and they are only
> really useful to active Commons devs
Done for Jenkins (Math only) and Continuum; these now send to commits@
>> 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: [ALL] Too much traffic on the "dev" ML
Posted by sebb <se...@gmail.com>.
On 16 January 2015 at 11:16, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 16/01/2015 12:03, sebb a écrit :
>
>> Commits already have a separate list.
>
> Ah thanks, I thought they were merged. Maybe we could move the Wiki
> notifications to the commits or notification lists, as well as the
> jenkins/continuum/gump messages.
There are very few Wiki or Gump messages.
I agree it might make sense to have CI messages go to the commit list,
as it is the commits that affect the test runs, and they are only
really useful to active Commons devs
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 16/01/2015 12:03, sebb a écrit :
> Commits already have a separate list.
Ah thanks, I thought they were merged. Maybe we could move the Wiki
notifications to the commits or notification lists, as well as the
jenkins/continuum/gump messages.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by sebb <se...@gmail.com>.
On 16 January 2015 at 10:49, Emmanuel Bourg <eb...@apache.org> wrote:
> If the volume of messages discourages new contributors from joining the
> project that's indeed an issue. We had an average of 400 messages per
> month in 2014, that's on par with maven-dev, half of tomcat-dev and 1/7
> of lucene-dev.
>
> I don't think splitting the list by component is a good idea though,
> this will kill the community (the 'all' list is unlikely to be popular).
+1
> But maybe we could consider separating the commits from the discussions
> (with a forced subscription to the commits for the PMC members)?
Commits already have a separate list.
Commons has the following lists:
commits
dev
issues
notification
user
http://mail-archives.apache.org/mod_mbox/#commons
Note: notification was set up for buildbot messages, but so far
attempts to redirect the output from commits have failed.
Infra are still investigating.
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 21:58:42 +0100, Emmanuel Bourg wrote:
> Le 16/01/2015 21:17, Gilles a écrit :
>
>> Between 2014-10-21 and now, the count of messages addressed to one
>> of the
>> "commons" lists is 4387, that is an average of about 50 per day
>> (1500 per
>> month).
>
> How did you get that number?
It's the number of mail accumulated in my "Trash" folder since the
mentioned date.
[Note: _all_ the mails sent to _all_ the lists <.....@commons.apache.org>
to which I have to be subscribed to follow the Commons Math project.]
> I got 400 by averaging the messages per
> month displayed on the mail archive:
>
> http://mail-archives.apache.org/mod_mbox/commons-dev/
Cf. the post I've just sent.
Regards,
Gilles
>
> Emmanuel Bourg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 16/01/2015 21:17, Gilles a écrit :
> Between 2014-10-21 and now, the count of messages addressed to one of the
> "commons" lists is 4387, that is an average of about 50 per day (1500 per
> month).
How did you get that number? I got 400 by averaging the messages per
month displayed on the mail archive:
http://mail-archives.apache.org/mod_mbox/commons-dev/
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by James Carman <ja...@carmanconsulting.com>.
Or, they could move to TLP.
On Fri, Jan 16, 2015 at 3:32 PM, Gary Gregory <ga...@gmail.com> wrote:
> I'm not sure what infra will say about managing multiple dev lists for one
> project, but we can ask.
>
> I would suggest that if a project wants its own dev list, a VOTE be called.
> Commons is still _one_ project, so all Commons PMC committers votes should
> count, not just folks involved in that single project.
>
> Gary
>
> On Fri, Jan 16, 2015 at 3:17 PM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
>> On Fri, 16 Jan 2015 09:58:12 -0700, Phil Steitz wrote:
>>
>>> On 1/16/15 5:05 AM, Jörg Schaible wrote:
>>>
>>>> Emmanuel Bourg wrote:
>>>>
>>>> If the volume of messages discourages new contributors from joining the
>>>>> project that's indeed an issue.
>>>>>
>>>>
>> Two or three people said so.
>>
>> We had an average of 400 messages per
>>>>> month in 2014,
>>>>>
>>>>
>> Between 2014-10-21 and now, the count of messages addressed to one of the
>> "commons" lists is 4387, that is an average of about 50 per day (1500 per
>> month).
>>
>> that's on par with maven-dev, half of tomcat-dev and 1/7
>>>>> of lucene-dev.
>>>>>
>>>>
>> The problem is not primarily "dev", it is that some people simply cannot
>> spend even more time to cater for all the Commons projects; yet we receive
>> all the notifications.
>> It's basic care for others' comfort to fix this at the source.
>> Is it so difficult to understand that I don't want to be flooded with
>> notifications of commits to a codebase which I don't contribute to?
>>
>> It's also significantly below where Commons used to be when we had a
>>> *lot* more active committers and contributors.
>>>
>>
>> So it can be worse. That's very comforting indeed.
>>
>>
>> Gilles
>>
>>
>>>>> I don't think splitting the list by component is a good idea though,
>>>>> this will kill the community (the 'all' list is unlikely to be popular).
>>>>>
>>>> +1
>>>>
>>>
>>> +1 and lets maybe cut the threads like this (self-referential) one ;)
>>>
>>> Phil
>>>
>>>>
>>>> - 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gary Gregory <ga...@gmail.com>.
I'm not sure what infra will say about managing multiple dev lists for one
project, but we can ask.
I would suggest that if a project wants its own dev list, a VOTE be called.
Commons is still _one_ project, so all Commons PMC committers votes should
count, not just folks involved in that single project.
Gary
On Fri, Jan 16, 2015 at 3:17 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Fri, 16 Jan 2015 09:58:12 -0700, Phil Steitz wrote:
>
>> On 1/16/15 5:05 AM, Jörg Schaible wrote:
>>
>>> Emmanuel Bourg wrote:
>>>
>>> If the volume of messages discourages new contributors from joining the
>>>> project that's indeed an issue.
>>>>
>>>
> Two or three people said so.
>
> We had an average of 400 messages per
>>>> month in 2014,
>>>>
>>>
> Between 2014-10-21 and now, the count of messages addressed to one of the
> "commons" lists is 4387, that is an average of about 50 per day (1500 per
> month).
>
> that's on par with maven-dev, half of tomcat-dev and 1/7
>>>> of lucene-dev.
>>>>
>>>
> The problem is not primarily "dev", it is that some people simply cannot
> spend even more time to cater for all the Commons projects; yet we receive
> all the notifications.
> It's basic care for others' comfort to fix this at the source.
> Is it so difficult to understand that I don't want to be flooded with
> notifications of commits to a codebase which I don't contribute to?
>
> It's also significantly below where Commons used to be when we had a
>> *lot* more active committers and contributors.
>>
>
> So it can be worse. That's very comforting indeed.
>
>
> Gilles
>
>
>>>> I don't think splitting the list by component is a good idea though,
>>>> this will kill the community (the 'all' list is unlikely to be popular).
>>>>
>>> +1
>>>
>>
>> +1 and lets maybe cut the threads like this (self-referential) one ;)
>>
>> Phil
>>
>>>
>>> - 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: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 09:58:12 -0700, Phil Steitz wrote:
> On 1/16/15 5:05 AM, Jörg Schaible wrote:
>> Emmanuel Bourg wrote:
>>
>>> If the volume of messages discourages new contributors from joining
>>> the
>>> project that's indeed an issue.
Two or three people said so.
>>> We had an average of 400 messages per
>>> month in 2014,
Between 2014-10-21 and now, the count of messages addressed to one of
the
"commons" lists is 4387, that is an average of about 50 per day (1500
per
month).
>>> that's on par with maven-dev, half of tomcat-dev and 1/7
>>> of lucene-dev.
The problem is not primarily "dev", it is that some people simply
cannot
spend even more time to cater for all the Commons projects; yet we
receive
all the notifications.
It's basic care for others' comfort to fix this at the source.
Is it so difficult to understand that I don't want to be flooded with
notifications of commits to a codebase which I don't contribute to?
> It's also significantly below where Commons used to be when we had a
> *lot* more active committers and contributors.
So it can be worse. That's very comforting indeed.
Gilles
>>>
>>> I don't think splitting the list by component is a good idea
>>> though,
>>> this will kill the community (the 'all' list is unlikely to be
>>> popular).
>> +1
>
> +1 and lets maybe cut the threads like this (self-referential) one ;)
>
> Phil
>>
>> - Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Phil Steitz <ph...@gmail.com>.
On 1/16/15 5:05 AM, Jörg Schaible wrote:
> Emmanuel Bourg wrote:
>
>> If the volume of messages discourages new contributors from joining the
>> project that's indeed an issue. We had an average of 400 messages per
>> month in 2014, that's on par with maven-dev, half of tomcat-dev and 1/7
>> of lucene-dev.
It's also significantly below where Commons used to be when we had a
*lot* more active committers and contributors.
>>
>> I don't think splitting the list by component is a good idea though,
>> this will kill the community (the 'all' list is unlikely to be popular).
> +1
+1 and lets maybe cut the threads like this (self-referential) one ;)
Phil
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Jörg Schaible <jo...@swisspost.com>.
Emmanuel Bourg wrote:
> If the volume of messages discourages new contributors from joining the
> project that's indeed an issue. We had an average of 400 messages per
> month in 2014, that's on par with maven-dev, half of tomcat-dev and 1/7
> of lucene-dev.
>
> I don't think splitting the list by component is a good idea though,
> this will kill the community (the 'all' list is unlikely to be popular).
+1
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 11:49:14 +0100, Emmanuel Bourg wrote:
> If the volume of messages discourages new contributors from joining
> the
> project that's indeed an issue. We had an average of 400 messages per
> month in 2014, that's on par with maven-dev, half of tomcat-dev and
> 1/7
> of lucene-dev.
>
> I don't think splitting the list by component is a good idea though,
> this will kill the community (the 'all' list is unlikely to be
> popular).
The "all" ML should be mandatory subscription: this is were decisions
(such as release votes) would be taken. [If a discussion is started on
another list, which then requires a larger audience, it could be
forwarded
to "all" with a link to the archived thread.]
> But maybe we could consider separating the commits from the
> discussions
> (with a forced subscription to the commits for the PMC members)?
One good thing would be the suppression of notifications for bulk
changes (like to the web site); when receiveing 10+ messages at once,
it is unlikely than I will browse them and check all the modifications,
so IMO high traffic lowers the quality of review.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Emmanuel Bourg <eb...@apache.org>.
If the volume of messages discourages new contributors from joining the
project that's indeed an issue. We had an average of 400 messages per
month in 2014, that's on par with maven-dev, half of tomcat-dev and 1/7
of lucene-dev.
I don't think splitting the list by component is a good idea though,
this will kill the community (the 'all' list is unlikely to be popular).
But maybe we could consider separating the commits from the discussions
(with a forced subscription to the commits for the PMC members)?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Kristian Rosenvold <kr...@apache.org>.
I'd say the problem is probably that you have too little mailing list
traffic incoming. Subscribe to a few more and you /will/ have to start
making inbox rules :)
Kristian (Who had the dubious honor of receiving more email than the
rest of my company altogether last year - 20 people)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br>.
Hi
I like reading all components' messages, but I think it is a good point to offer an alternative to others who wouldn't feel it was productive to receive messages from all components.
What about keeping the commons-dev mailing list as is, and we ask infra to help us, by creating mailing list mirrors? Perhaps they could create filters in the server that would match the component name in the subject (e.g. [lang|LANG]) and deliver only those messages to subscribers? Replies to these mirrors would go to the commons-dev mailing list.
This way we would remove the burden from users having to configure their e-mail clients/providers (when these support filtering) and offer an alternative for others. For others who need/like to read all messages it ill continue the same as before.
Bruno
>________________________________
> From: Gilles <gi...@harfang.homelinux.org>
>To: Commons Developers List <de...@commons.apache.org>
>Sent: Thursday, January 15, 2015 10:47 PM
>Subject: [ALL] Too much traffic on the "dev" ML
>
>
>Hi.
>
>In the discussion that started about RDF, it seems that the
>traffic volume is a stumbling block.
>[For some time now, it has been a growing nuisance, and the
>usual dismissal about filters won't change the fact: Setting
>up a filter that will redirect stuff to /dev/null is a waste
>of bandwidth.]
>
>If different ML are created, people interested in everything
>can subscribe _once_, and nothing will change for them.
>For people who spend a lot of time just deleting dozens messages
>and notifications a day, it will be a relief.
>
>Maintaining community conversation is not a problem: just
>create an "all-dev@commons.apache.org" ML for things that
>need input form a larger audience (like votes).
>
>
>Best regards,
>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: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 21:50:59 +0100, Oliver Heger wrote:
> Am 16.01.2015 um 16:19 schrieb Duncan Jones:
>> On 16 January 2015 at 14:54, Torsten Curdt <tc...@vafer.org> wrote:
>>>> Concerning [Math], when the possibility was raised, the majority
>>>> thought that development within Commons had practical advantages
>>>> (through shared burden of the development environment).
>>>>
>>>> I'm stating again the fact that nobody is involved in a "Commons"
>>>> project programming-wise; hence it does not make sense, in
>>>> principle,
>>>> to have to share the programming discussions on the same ML.
>>>
>>> The conclusion you derive from the fact is only an opinion though.
>>> Maybe it does make sense for others to hear what's going on in
>>> Math?
>>> ...and be it just for the board reports?
>>>
>>>
>>>> If it did, all the Apache (programming) project could as well
>>>> share
>>>> the same list. [We'd just have to set up filters, wouldn't we?]
>>>
>>> That comparison is pretty flawed as those projects are not tiny
>>> components.
>>>
>>> I've never a great fan of umbrellas but the components are so small
>>> -
>>> I don't see another option. The thought of components to go TLP
>>> feels
>>> just plain silly to me. Hence it would be great to work together as
>>> a
>>> community that takes care of those components.
>>>
>>> While from a practical standpoint (if everyone filters anyway) you
>>> might be right, my guess is that a community with many list will
>>> not
>>> have the same feeling of affiliation.
>>
>> I think the sense of community achieved by receiving all emails is
>> minimal to nil. Most people appear to set up filters, which is a lot
>> of duplicated work and prone to error. I've missed emails before
>> because they were misspelled "[ANOUNCE]" , which didn't trigger my
>> filters. I could use the mail archives if I needed to see emails
>> from
>> another component to which I'm not subscribed.
>
> Well, I have rather the impression that there are many of us
> interested
> in multiple components or at least specific aspects/discussions on
> components. I always found this valuable.
Mileages do vary. I agree on the uselfulness (cf. the message I've just
sent) in principle, but the RDF people explicitly mentioned it as a
practical drawback (and this, in turn had me starting this thread).
>
> Oliver
>
>>
>> I would be in favour of total segregation, even including issues and
>> commits, but I appreciate the latter two might be challenging to
>> implement.
But the latter is what would be most relieving.
Regards,
Gilles
>>
>> Duncan
>>
>>>
>>> cheers,
>>> Torsten
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 16.01.2015 um 16:19 schrieb Duncan Jones:
> On 16 January 2015 at 14:54, Torsten Curdt <tc...@vafer.org> wrote:
>>> Concerning [Math], when the possibility was raised, the majority
>>> thought that development within Commons had practical advantages
>>> (through shared burden of the development environment).
>>>
>>> I'm stating again the fact that nobody is involved in a "Commons"
>>> project programming-wise; hence it does not make sense, in principle,
>>> to have to share the programming discussions on the same ML.
>>
>> The conclusion you derive from the fact is only an opinion though.
>> Maybe it does make sense for others to hear what's going on in Math?
>> ...and be it just for the board reports?
>>
>>
>>> If it did, all the Apache (programming) project could as well share
>>> the same list. [We'd just have to set up filters, wouldn't we?]
>>
>> That comparison is pretty flawed as those projects are not tiny components.
>>
>> I've never a great fan of umbrellas but the components are so small -
>> I don't see another option. The thought of components to go TLP feels
>> just plain silly to me. Hence it would be great to work together as a
>> community that takes care of those components.
>>
>> While from a practical standpoint (if everyone filters anyway) you
>> might be right, my guess is that a community with many list will not
>> have the same feeling of affiliation.
>
> I think the sense of community achieved by receiving all emails is
> minimal to nil. Most people appear to set up filters, which is a lot
> of duplicated work and prone to error. I've missed emails before
> because they were misspelled "[ANOUNCE]" , which didn't trigger my
> filters. I could use the mail archives if I needed to see emails from
> another component to which I'm not subscribed.
Well, I have rather the impression that there are many of us interested
in multiple components or at least specific aspects/discussions on
components. I always found this valuable.
Oliver
>
> I would be in favour of total segregation, even including issues and
> commits, but I appreciate the latter two might be challenging to
> implement.
>
> Duncan
>
>>
>> cheers,
>> Torsten
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 16/01/2015 17:25, Torsten Curdt a écrit :
> Sorry - I am done with this thread.
err... wait ! We haven't talked about logging and line length yet ;)
Emmanuel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Torsten Curdt <tc...@vafer.org>.
>> Then let's ask the next question: Why be a Commons project?
>
> I gave one answer a few posts ago (several times).
Guess I missed that in all that traffic :-p
Sorry - I am done with this thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 16:56:30 +0100, Torsten Curdt wrote:
>> I would be in favour of total segregation, even including issues and
>> commits, but I appreciate the latter two might be challenging to
>> implement.
>
> Then let's ask the next question: Why be a Commons project?
I gave one answer a few posts ago (several times).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Torsten Curdt <tc...@vafer.org>.
> I would be in favour of total segregation, even including issues and
> commits, but I appreciate the latter two might be challenging to
> implement.
Then let's ask the next question: Why be a Commons project?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Duncan Jones <du...@wortharead.com>.
On 16 January 2015 at 14:54, Torsten Curdt <tc...@vafer.org> wrote:
>> Concerning [Math], when the possibility was raised, the majority
>> thought that development within Commons had practical advantages
>> (through shared burden of the development environment).
>>
>> I'm stating again the fact that nobody is involved in a "Commons"
>> project programming-wise; hence it does not make sense, in principle,
>> to have to share the programming discussions on the same ML.
>
> The conclusion you derive from the fact is only an opinion though.
> Maybe it does make sense for others to hear what's going on in Math?
> ...and be it just for the board reports?
>
>
>> If it did, all the Apache (programming) project could as well share
>> the same list. [We'd just have to set up filters, wouldn't we?]
>
> That comparison is pretty flawed as those projects are not tiny components.
>
> I've never a great fan of umbrellas but the components are so small -
> I don't see another option. The thought of components to go TLP feels
> just plain silly to me. Hence it would be great to work together as a
> community that takes care of those components.
>
> While from a practical standpoint (if everyone filters anyway) you
> might be right, my guess is that a community with many list will not
> have the same feeling of affiliation.
I think the sense of community achieved by receiving all emails is
minimal to nil. Most people appear to set up filters, which is a lot
of duplicated work and prone to error. I've missed emails before
because they were misspelled "[ANOUNCE]" , which didn't trigger my
filters. I could use the mail archives if I needed to see emails from
another component to which I'm not subscribed.
I would be in favour of total segregation, even including issues and
commits, but I appreciate the latter two might be challenging to
implement.
Duncan
>
> cheers,
> Torsten
>
> ---------------------------------------------------------------------
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Benedikt Ritter <br...@apache.org>.
2015-01-16 17:21 GMT+01:00 Ben McCann <be...@benmccann.com>:
> I find the whole I idea of a mailing list very 1990s.
+1
I've heard that from people several times...
> I'd much prefer
> something like Google Groups where I can set my notification preferences
> easily to send me updates only on certain threads such as threads I've
> started, which has a nice easily browsable and searchable web interface,
> and where I do not have to go through a signup process for each new
> group/list I want to post to. I feel many of the problems folks are talking
> about here are caused by using a frustrating technology. E.g. it was
> mentioned that if we split mailing lists that joining every list would be
> very painful. Perhaps that's because the process of joining just a single
> list is too difficult. Having to setup filters is also not very
> user-friendly. How do I make a filter that says only put threads on which
> I've participated in my inbox? There's probably a way, but it's not as
> obvious as clicking a single button. And even with filters I still don't
> want most of this garbage coming to my mail account anyway because it
> pollutes my search results when I'm looking for something I do care about.
> I signed up for the dev list just so that I could ask that someone reviews
> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
> (which
> I still need help with), but I really have no interest in getting any
> commons mail beyond that. I've never participated in any of these other
> projects and flooding my inbox is just frustrating and isn't going to cause
> me to start. The web interface for mailing list archives is truly
> horrendous.
>
>
>
> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
> > On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
> >
> >> Was it mentioned that anybody would be forbidden to subscribe to any
> >>> ML they see fit?
> >>>
> >>
> >> You missed my point - but never mind.
> >>
> >
> > What was it?
> >
> > Judging from your comments below, you completely missed mine.
> >
> >
> >
> >> That comparison is pretty flawed as those projects are not tiny
> >>>> components.
> >>>>
> >>>
> >>>
> >>> I'm not talking about the size of components, but the size of the
> >>> ML traffic.
> >>>
> >>
> >> So just because a component/project has a lot of ML traffic you want
> >> to make it TLP?
> >>
> >
> > I never said that.
> > I'm only complaining about ML traffic.
> >
> > Usually it should be about having enough active committers and users.
> >> While this might contribute to ML traffic, it doesn't necessarily
> >> mean the same.
> >>
> >>
> >> I've never a great fan of umbrellas but the components are so small -
> >>>> I don't see another option. The thought of components to go TLP feels
> >>>> just plain silly to me. Hence it would be great to work together as a
> >>>> community that takes care of those components.
> >>>>
> >>>
> >>>
> >>> The idea of "Commons Math" being a component is silly, but we can
> accept
> >>> silly things that result from history (and consider the practical
> >>> advantages, as I noted elsewhere).
> >>>
> >>
> >> Well, by the current definition it's not an Apache project. Call it
> >> sub-project if you like - I don't care.
> >>
> >
> > What I'm calling "project" is a _programming_ project; that's the word
> > I'm used to; do you have another one?
> > Every component is a separate programming project, it's a simple fact.
> >
> > At some stage we decided to call it component. After all I see it as
> >> a library.
> >>
> >> Do you think it's more and needs to be raised to the level to full
> >> blown project like hadoop or httpd?
> >> Not sure it Math holds that comparison but you are welcome to convince
> us.
> >>
> >
> > I think that this has nothing to do with this thread.
> >
> >
> >> If it depends on the name of the list, I guess that the "sense of
> >>> community" is not very developed...
> >>>
> >>
> >> And that's what I call an oversimplification.
> >>
> >>
> > You brought that up (one community == one list). Or another missed point?
> >
> >
> > Gilles
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> about.me/benmccann
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [ALL] Too much traffic on the "dev" ML
Posted by Ole Ersoy <ol...@gmail.com>.
On 01/17/2015 01:16 PM, Duncan Jones wrote:
> On 17 January 2015 at 16:59, Ole Ersoy <ol...@gmail.com> wrote:
>> GIlles,
>>
>> Well said as always.
>>
>> With respect to the goal of growing the community, I think everyone agrees
>> that that's a good goal.
>> So if we pick tools that developers are most likely to be used to, then they
>> are more likely to join.
>>
>> The number of open source projects is growing everyday, and more and more
>> developers are using github
>> and stackoverflow facilities to get things done. It's becoming the norm.
>>
>> So we developers arrive at Apache's github repository and see "Watch" turned
>> off, it gives a backward appearance.
>>
>> Stackoverflow is great at:
>> - Indexing questions
>> - Providing a knowledge repository
>> - Tagging and filtering content
>> - Syntax highlighting content
>> - Processing new questions and search previous answers
>>
>> This enhances the view of and intrinsic value of the project that these
>> services wrap.
>> It's also a great secondary source of documentation and trails of
>> experimentation.
>>
>> As a matter of fact I think if design discussions / questions were conducted
>> on stackoverflow,
>> everyone would be pleasantly surprised at the increase in sharp feedback.
>> These individuals
>> might subsequently join the community, because they find the design
>> fascinating.
> Stack Overflow is _not_ the right place to conduct design discussions
> about Commons projects. Such questions would be closed, since
> discussion is discouraged.
Closed questions are tagged with:
============================
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
============================
So it encourages facts, references, and expertise which is good right?
For example we could ask:
What's the shortest most concise way to calculate least squares for an array of doubles using Java 8 streams?
Also there is a `design` tag. Here's a list of questions tagged with design:
http://stackoverflow.com/questions/tagged/design
Specific example:
http://stackoverflow.com/questions/27988978/usage-of-instaceof-when-polymorphism-is-not-possible
So it seems that as long as it's kept concrete, verifiable, and targeted at achieving a specific goal it passes.
Cheers,
Ole
Cheers, - Ole On 01/17/2015 08:23 AM, Gilles wrote:
>>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>> I agree - we're hung up on a clown from the 90s. It's so much
>>>> simpler click watch on github and get notifications. Also
>>>> stackoverflow has a much broader Java community and having traffic go
>>>> through it could benefit this community.
>>>
>>> I'm afraid that the main problem is not the tool.
>>>
>>> Step 1: an issue is felt as a problem by some people (from the
>>> community or might-be contributors)
>>> Step 2: people (from the community) who don't feel the problem
>>> try to demonstrate that there isn't a problem, thus
>>> dismissing the (argumented) feeling of others
>>>
>>> This can destroy a community, or at least prevent its expansion.
>>> [And the "Commons" project's (with the word "project" as in "an
>>> Apache project") community certainly does not benefit from a
>>> pool of contributors commensurate with its purported goal and
>>> user base.]
>>>
>>> On the practical side, I'm not (yet) against having a single "dev"
>>> list: discussions about design are usually interesting even if
>>> applied to another project's codebase (with the the word "project"
>>> as in "programming project").
>>>
>>> But lately, the flood of automatic notifications (commits and CI)
>>> has drowned the useful discussions.
>>> For people who do not contribute to a project (i.e. neither
>>> providing code nor checking it), a commit diff is just noise
>>> because they lack context (not being aquainted with the codebase).
>>>
>>> The Commons community's implied answer to the stated fact is
>>> that people who feel that way should change their perception of
>>> reality, or go away.
>>>
>>> The respectful answer would be to solve the problem with the
>>> readily available technology of the 1990s: separate MLs for
>>> each project's _notifications_ (with the word "project" as in
>>> "programming project").
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>>> Ole
>>>>
>>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>>>> something like Google Groups where I can set my notification preferences
>>>>> easily to send me updates only on certain threads such as threads I've
>>>>> started, which has a nice easily browsable and searchable web interface,
>>>>> and where I do not have to go through a signup process for each new
>>>>> group/list I want to post to. I feel many of the problems folks are
>>>>> talking
>>>>> about here are caused by using a frustrating technology. E.g. it was
>>>>> mentioned that if we split mailing lists that joining every list would
>>>>> be
>>>>> very painful. Perhaps that's because the process of joining just a
>>>>> single
>>>>> list is too difficult. Having to setup filters is also not very
>>>>> user-friendly. How do I make a filter that says only put threads on
>>>>> which
>>>>> I've participated in my inbox? There's probably a way, but it's not as
>>>>> obvious as clicking a single button. And even with filters I still don't
>>>>> want most of this garbage coming to my mail account anyway because it
>>>>> pollutes my search results when I'm looking for something I do care
>>>>> about.
>>>>> I signed up for the dev list just so that I could ask that someone
>>>>> reviews
>>>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>>>> (which
>>>>> I still need help with), but I really have no interest in getting any
>>>>> commons mail beyond that. I've never participated in any of these other
>>>>> projects and flooding my inbox is just frustrating and isn't going to
>>>>> cause
>>>>> me to start. The web interface for mailing list archives is truly
>>>>> horrendous.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>>
>>>>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>>>> ML they see fit?
>>>>>>>>
>>>>>>> You missed my point - but never mind.
>>>>>>>
>>>>>> What was it?
>>>>>>
>>>>>> Judging from your comments below, you completely missed mine.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>>>>> components.
>>>>>>>>>
>>>>>>>> I'm not talking about the size of components, but the size of the
>>>>>>>> ML traffic.
>>>>>>>>
>>>>>>> So just because a component/project has a lot of ML traffic you want
>>>>>>> to make it TLP?
>>>>>>>
>>>>>> I never said that.
>>>>>> I'm only complaining about ML traffic.
>>>>>>
>>>>>> Usually it should be about having enough active committers and users.
>>>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>>>> mean the same.
>>>>>>>
>>>>>>>
>>>>>>> I've never a great fan of umbrellas but the components are so small
>>>>>>> -
>>>>>>>>> I don't see another option. The thought of components to go TLP
>>>>>>>>> feels
>>>>>>>>> just plain silly to me. Hence it would be great to work together as
>>>>>>>>> a
>>>>>>>>> community that takes care of those components.
>>>>>>>>>
>>>>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>>>>> accept
>>>>>>>> silly things that result from history (and consider the practical
>>>>>>>> advantages, as I noted elsewhere).
>>>>>>>>
>>>>>>> Well, by the current definition it's not an Apache project. Call it
>>>>>>> sub-project if you like - I don't care.
>>>>>>>
>>>>>> What I'm calling "project" is a _programming_ project; that's the word
>>>>>> I'm used to; do you have another one?
>>>>>> Every component is a separate programming project, it's a simple fact.
>>>>>>
>>>>>> At some stage we decided to call it component. After all I see it as
>>>>>>> a library.
>>>>>>>
>>>>>>> Do you think it's more and needs to be raised to the level to full
>>>>>>> blown project like hadoop or httpd?
>>>>>>> Not sure it Math holds that comparison but you are welcome to convince
>>>>>>> us.
>>>>>>>
>>>>>> I think that this has nothing to do with this thread.
>>>>>>
>>>>>>
>>>>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>>>> community" is not very developed...
>>>>>>>>
>>>>>>> And that's what I call an oversimplification.
>>>>>>>
>>>>>>>
>>>>>> You brought that up (one community == one list). Or another missed
>>>>>> point?
>>>>>>
>>>>>>
>>>>>> 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
>>
> ---------------------------------------------------------------------
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Duncan Jones <du...@wortharead.com>.
On 17 January 2015 at 16:59, Ole Ersoy <ol...@gmail.com> wrote:
> GIlles,
>
> Well said as always.
>
> With respect to the goal of growing the community, I think everyone agrees
> that that's a good goal.
> So if we pick tools that developers are most likely to be used to, then they
> are more likely to join.
>
> The number of open source projects is growing everyday, and more and more
> developers are using github
> and stackoverflow facilities to get things done. It's becoming the norm.
>
> So we developers arrive at Apache's github repository and see "Watch" turned
> off, it gives a backward appearance.
>
> Stackoverflow is great at:
> - Indexing questions
> - Providing a knowledge repository
> - Tagging and filtering content
> - Syntax highlighting content
> - Processing new questions and search previous answers
>
> This enhances the view of and intrinsic value of the project that these
> services wrap.
> It's also a great secondary source of documentation and trails of
> experimentation.
>
> As a matter of fact I think if design discussions / questions were conducted
> on stackoverflow,
> everyone would be pleasantly surprised at the increase in sharp feedback.
> These individuals
> might subsequently join the community, because they find the design
> fascinating.
Stack Overflow is _not_ the right place to conduct design discussions
about Commons projects. Such questions would be closed, since
discussion is discouraged.
Also see this meta question, which discusses using SO as a support
forum: http://meta.stackexchange.com/q/3966/192221
>
> Cheers,
> - Ole
>
>
> On 01/17/2015 08:23 AM, Gilles wrote:
>>
>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>
>>> I agree - we're hung up on a clown from the 90s. It's so much
>>> simpler click watch on github and get notifications. Also
>>> stackoverflow has a much broader Java community and having traffic go
>>> through it could benefit this community.
>>
>>
>> I'm afraid that the main problem is not the tool.
>>
>> Step 1: an issue is felt as a problem by some people (from the
>> community or might-be contributors)
>> Step 2: people (from the community) who don't feel the problem
>> try to demonstrate that there isn't a problem, thus
>> dismissing the (argumented) feeling of others
>>
>> This can destroy a community, or at least prevent its expansion.
>> [And the "Commons" project's (with the word "project" as in "an
>> Apache project") community certainly does not benefit from a
>> pool of contributors commensurate with its purported goal and
>> user base.]
>>
>> On the practical side, I'm not (yet) against having a single "dev"
>> list: discussions about design are usually interesting even if
>> applied to another project's codebase (with the the word "project"
>> as in "programming project").
>>
>> But lately, the flood of automatic notifications (commits and CI)
>> has drowned the useful discussions.
>> For people who do not contribute to a project (i.e. neither
>> providing code nor checking it), a commit diff is just noise
>> because they lack context (not being aquainted with the codebase).
>>
>> The Commons community's implied answer to the stated fact is
>> that people who feel that way should change their perception of
>> reality, or go away.
>>
>> The respectful answer would be to solve the problem with the
>> readily available technology of the 1990s: separate MLs for
>> each project's _notifications_ (with the word "project" as in
>> "programming project").
>>
>>
>> Regards,
>> Gilles
>>
>>> Ole
>>>
>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>
>>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>>> something like Google Groups where I can set my notification preferences
>>>> easily to send me updates only on certain threads such as threads I've
>>>> started, which has a nice easily browsable and searchable web interface,
>>>> and where I do not have to go through a signup process for each new
>>>> group/list I want to post to. I feel many of the problems folks are
>>>> talking
>>>> about here are caused by using a frustrating technology. E.g. it was
>>>> mentioned that if we split mailing lists that joining every list would
>>>> be
>>>> very painful. Perhaps that's because the process of joining just a
>>>> single
>>>> list is too difficult. Having to setup filters is also not very
>>>> user-friendly. How do I make a filter that says only put threads on
>>>> which
>>>> I've participated in my inbox? There's probably a way, but it's not as
>>>> obvious as clicking a single button. And even with filters I still don't
>>>> want most of this garbage coming to my mail account anyway because it
>>>> pollutes my search results when I'm looking for something I do care
>>>> about.
>>>> I signed up for the dev list just so that I could ask that someone
>>>> reviews
>>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>>> (which
>>>> I still need help with), but I really have no interest in getting any
>>>> commons mail beyond that. I've never participated in any of these other
>>>> projects and flooding my inbox is just frustrating and isn't going to
>>>> cause
>>>> me to start. The web interface for mailing list archives is truly
>>>> horrendous.
>>>>
>>>>
>>>>
>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>
>>>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>>>
>>>>>>> ML they see fit?
>>>>>>>
>>>>>> You missed my point - but never mind.
>>>>>>
>>>>> What was it?
>>>>>
>>>>> Judging from your comments below, you completely missed mine.
>>>>>
>>>>>
>>>>>
>>>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>>>>
>>>>>>>> components.
>>>>>>>>
>>>>>>>
>>>>>>> I'm not talking about the size of components, but the size of the
>>>>>>> ML traffic.
>>>>>>>
>>>>>> So just because a component/project has a lot of ML traffic you want
>>>>>> to make it TLP?
>>>>>>
>>>>> I never said that.
>>>>> I'm only complaining about ML traffic.
>>>>>
>>>>> Usually it should be about having enough active committers and users.
>>>>>>
>>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>>> mean the same.
>>>>>>
>>>>>>
>>>>>> I've never a great fan of umbrellas but the components are so small
>>>>>> -
>>>>>>>>
>>>>>>>> I don't see another option. The thought of components to go TLP
>>>>>>>> feels
>>>>>>>> just plain silly to me. Hence it would be great to work together as
>>>>>>>> a
>>>>>>>> community that takes care of those components.
>>>>>>>>
>>>>>>>
>>>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>>>> accept
>>>>>>> silly things that result from history (and consider the practical
>>>>>>> advantages, as I noted elsewhere).
>>>>>>>
>>>>>> Well, by the current definition it's not an Apache project. Call it
>>>>>> sub-project if you like - I don't care.
>>>>>>
>>>>> What I'm calling "project" is a _programming_ project; that's the word
>>>>> I'm used to; do you have another one?
>>>>> Every component is a separate programming project, it's a simple fact.
>>>>>
>>>>> At some stage we decided to call it component. After all I see it as
>>>>>>
>>>>>> a library.
>>>>>>
>>>>>> Do you think it's more and needs to be raised to the level to full
>>>>>> blown project like hadoop or httpd?
>>>>>> Not sure it Math holds that comparison but you are welcome to convince
>>>>>> us.
>>>>>>
>>>>> I think that this has nothing to do with this thread.
>>>>>
>>>>>
>>>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>>>
>>>>>>> community" is not very developed...
>>>>>>>
>>>>>> And that's what I call an oversimplification.
>>>>>>
>>>>>>
>>>>> You brought that up (one community == one list). Or another missed
>>>>> point?
>>>>>
>>>>>
>>>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Ole Ersoy <ol...@gmail.com>.
GIlles,
Well said as always.
With respect to the goal of growing the community, I think everyone agrees that that's a good goal.
So if we pick tools that developers are most likely to be used to, then they are more likely to join.
The number of open source projects is growing everyday, and more and more developers are using github
and stackoverflow facilities to get things done. It's becoming the norm.
So we developers arrive at Apache's github repository and see "Watch" turned off, it gives a backward appearance.
Stackoverflow is great at:
- Indexing questions
- Providing a knowledge repository
- Tagging and filtering content
- Syntax highlighting content
- Processing new questions and search previous answers
This enhances the view of and intrinsic value of the project that these services wrap.
It's also a great secondary source of documentation and trails of experimentation.
As a matter of fact I think if design discussions / questions were conducted on stackoverflow,
everyone would be pleasantly surprised at the increase in sharp feedback. These individuals
might subsequently join the community, because they find the design fascinating.
Cheers,
- Ole
On 01/17/2015 08:23 AM, Gilles wrote:
> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>> I agree - we're hung up on a clown from the 90s. It's so much
>> simpler click watch on github and get notifications. Also
>> stackoverflow has a much broader Java community and having traffic go
>> through it could benefit this community.
>
> I'm afraid that the main problem is not the tool.
>
> Step 1: an issue is felt as a problem by some people (from the
> community or might-be contributors)
> Step 2: people (from the community) who don't feel the problem
> try to demonstrate that there isn't a problem, thus
> dismissing the (argumented) feeling of others
>
> This can destroy a community, or at least prevent its expansion.
> [And the "Commons" project's (with the word "project" as in "an
> Apache project") community certainly does not benefit from a
> pool of contributors commensurate with its purported goal and
> user base.]
>
> On the practical side, I'm not (yet) against having a single "dev"
> list: discussions about design are usually interesting even if
> applied to another project's codebase (with the the word "project"
> as in "programming project").
>
> But lately, the flood of automatic notifications (commits and CI)
> has drowned the useful discussions.
> For people who do not contribute to a project (i.e. neither
> providing code nor checking it), a commit diff is just noise
> because they lack context (not being aquainted with the codebase).
>
> The Commons community's implied answer to the stated fact is
> that people who feel that way should change their perception of
> reality, or go away.
>
> The respectful answer would be to solve the problem with the
> readily available technology of the 1990s: separate MLs for
> each project's _notifications_ (with the word "project" as in
> "programming project").
>
>
> Regards,
> Gilles
>
>> Ole
>>
>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>> something like Google Groups where I can set my notification preferences
>>> easily to send me updates only on certain threads such as threads I've
>>> started, which has a nice easily browsable and searchable web interface,
>>> and where I do not have to go through a signup process for each new
>>> group/list I want to post to. I feel many of the problems folks are talking
>>> about here are caused by using a frustrating technology. E.g. it was
>>> mentioned that if we split mailing lists that joining every list would be
>>> very painful. Perhaps that's because the process of joining just a single
>>> list is too difficult. Having to setup filters is also not very
>>> user-friendly. How do I make a filter that says only put threads on which
>>> I've participated in my inbox? There's probably a way, but it's not as
>>> obvious as clicking a single button. And even with filters I still don't
>>> want most of this garbage coming to my mail account anyway because it
>>> pollutes my search results when I'm looking for something I do care about.
>>> I signed up for the dev list just so that I could ask that someone reviews
>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186> (which
>>> I still need help with), but I really have no interest in getting any
>>> commons mail beyond that. I've never participated in any of these other
>>> projects and flooding my inbox is just frustrating and isn't going to cause
>>> me to start. The web interface for mailing list archives is truly
>>> horrendous.
>>>
>>>
>>>
>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>
>>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>> ML they see fit?
>>>>>>
>>>>> You missed my point - but never mind.
>>>>>
>>>> What was it?
>>>>
>>>> Judging from your comments below, you completely missed mine.
>>>>
>>>>
>>>>
>>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>>> components.
>>>>>>>
>>>>>>
>>>>>> I'm not talking about the size of components, but the size of the
>>>>>> ML traffic.
>>>>>>
>>>>> So just because a component/project has a lot of ML traffic you want
>>>>> to make it TLP?
>>>>>
>>>> I never said that.
>>>> I'm only complaining about ML traffic.
>>>>
>>>> Usually it should be about having enough active committers and users.
>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>> mean the same.
>>>>>
>>>>>
>>>>> I've never a great fan of umbrellas but the components are so small -
>>>>>>> I don't see another option. The thought of components to go TLP feels
>>>>>>> just plain silly to me. Hence it would be great to work together as a
>>>>>>> community that takes care of those components.
>>>>>>>
>>>>>>
>>>>>> The idea of "Commons Math" being a component is silly, but we can accept
>>>>>> silly things that result from history (and consider the practical
>>>>>> advantages, as I noted elsewhere).
>>>>>>
>>>>> Well, by the current definition it's not an Apache project. Call it
>>>>> sub-project if you like - I don't care.
>>>>>
>>>> What I'm calling "project" is a _programming_ project; that's the word
>>>> I'm used to; do you have another one?
>>>> Every component is a separate programming project, it's a simple fact.
>>>>
>>>> At some stage we decided to call it component. After all I see it as
>>>>> a library.
>>>>>
>>>>> Do you think it's more and needs to be raised to the level to full
>>>>> blown project like hadoop or httpd?
>>>>> Not sure it Math holds that comparison but you are welcome to convince us.
>>>>>
>>>> I think that this has nothing to do with this thread.
>>>>
>>>>
>>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>> community" is not very developed...
>>>>>>
>>>>> And that's what I call an oversimplification.
>>>>>
>>>>>
>>>> You brought that up (one community == one list). Or another missed point?
>>>>
>>>>
>>>> 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: [ALL] Too much traffic on the "dev" ML
Posted by Phil Steitz <ph...@gmail.com>.
On 1/17/15 3:36 PM, Emmanuel Bourg wrote:
> Le 17/01/2015 23:18, Phil Steitz a écrit :
>
>> Sorry for the hijack; but I agree this is noise that would be nice
>> to suppress.
> +1
>
> I suggest to leave the bugs fixed and avoid closing them, that's useless.
I disagree, but it may be a matter of personal taste / habit. There
is value, IMO in distinguishing the bugs that have been fixed in
pre-release source from those that are fixed in a release. Fine by
me if others want to do things differently though.
Thanks, Sebb for the pointer. I used to do it incorrectly by
turning off notification for the component while I did the changes
one at a time. That is not possible any more because of the common
notification structure and the fact I am no longer a JIRA admin.
If those of us who do it agree to do bulk changes with muted
notifications that will help.
Thanks!
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: [ALL] Too much traffic on the "dev" ML
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello Ben,
I was actually looking for this switch before. After releasing VFS
there would be a few hundred closed bugs, so it comes in handy.
However I dont see a bulk operation interface. It is supposed to be
under "Tools" and requires a global "Bulk" permission. But I dont see a
tools menu. Or at least I have no idea where to look for it :)
Can you confirm that this is restricted and that we have some people on
the list who could use it (it is only rarely needed so we can request
the execution by mail).
Gruss
Bernd
Am Sun,
18 Jan 2015 13:21:17 +0100 schrieb Benedikt Ritter <br...@apache.org>:
> 2015-01-17 23:36 GMT+01:00 Emmanuel Bourg <eb...@apache.org>:
>
> > Le 17/01/2015 23:18, Phil Steitz a écrit :
> >
> > > Sorry for the hijack; but I agree this is noise that would be nice
> > > to suppress.
> >
> > +1
> >
> > I suggest to leave the bugs fixed and avoid closing them, that's
> > useless.
> >
>
> When you do bulk operations in Jira, there is a checkbox where you can
> disable mails for this bulk change. I've always let jira send the
> mails for archiving pruposes. But we could simply set the checkbox
> and closing the issues wouldn't spam the ML.
>
>
> >
> > 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: [ALL] Too much traffic on the "dev" ML
Posted by Benedikt Ritter <br...@apache.org>.
2015-01-17 23:36 GMT+01:00 Emmanuel Bourg <eb...@apache.org>:
> Le 17/01/2015 23:18, Phil Steitz a écrit :
>
> > Sorry for the hijack; but I agree this is noise that would be nice
> > to suppress.
>
> +1
>
> I suggest to leave the bugs fixed and avoid closing them, that's useless.
>
When you do bulk operations in Jira, there is a checkbox where you can
disable mails for this bulk change. I've always let jira send the mails for
archiving pruposes. But we could simply set the checkbox and closing the
issues wouldn't spam the ML.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 17/01/2015 23:18, Phil Steitz a écrit :
> Sorry for the hijack; but I agree this is noise that would be nice
> to suppress.
+1
I suggest to leave the bugs fixed and avoid closing them, that's useless.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by sebb <se...@gmail.com>.
On 17 January 2015 at 22:18, Phil Steitz <ph...@gmail.com> wrote:
> On 1/17/15 3:11 PM, sebb wrote:
>> On 17 January 2015 at 16:29, Mark Fortner <ph...@gmail.com> wrote:
>>> Bulk JIRA changes prior to a release tend to swamp the list. Perhaps it
>>> would be better to close the issue as the work is done.
>> The convention is to resolve the issue when the work is done and close
>> the issues after the release.
>>
>> When bulk closing lots of issues, it's easy enough to suppress the email.
>
> How, exactly? I used to be able to do this, but I don't seem to
> have the karma now or maybe I just forgot how.
Select the issues that you want to change
There should be a Tools menu item top right which includes Bulk change.
> Sorry for the hijack; but I agree this is noise that would be nice
> to suppress.
>
> The website commits are another morass. I find that when I do it
> "manually" - command line checkin as opposed to counting on the
> maven site thingy - there is often much less noise. Is there a way
> to do that "silently" as well?
Dunno.
Adjusting the way that Maven does anything is not generally very easy
as it is often buried in multiple layers of plugins.
It may be that svnmucc could be used; that tends to be a lot quieter
than svn commit.
We do now have a notifications list which is intended for build-bot commits.
It would make sense for commits to the live site to go there as well.
Those commits did not exist before svnpubsub, and they are not critical.
I assume that is something Infra can do quite easily.
The main commits list would then remain for code commits and source
document updates.
> Phil
>>
>>> Mark
>>> On Jan 17, 2015 8:11 AM, "Gilles" <gi...@harfang.homelinux.org> wrote:
>>>
>>>> On Sat, 17 Jan 2015 16:36:55 +0100, Gilles wrote:
>>>>
>>>>> On Sat, 17 Jan 2015 15:00:34 +0000, sebb wrote:
>>>>>
>>>>>> On 17 January 2015 at 14:23, Gilles <gi...@harfang.homelinux.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>>>>>
>>>>>>>> I agree - we're hung up on a clown from the 90s. It's so much
>>>>>>>> simpler click watch on github and get notifications. Also
>>>>>>>> stackoverflow has a much broader Java community and having traffic go
>>>>>>>> through it could benefit this community.
>>>>>>>>
>>>>>>>
>>>>>>> I'm afraid that the main problem is not the tool.
>>>>>>>
>>>>>>> Step 1: an issue is felt as a problem by some people (from the
>>>>>>> community or might-be contributors)
>>>>>>> Step 2: people (from the community) who don't feel the problem
>>>>>>> try to demonstrate that there isn't a problem, thus
>>>>>>> dismissing the (argumented) feeling of others
>>>>>>>
>>>>>>> This can destroy a community, or at least prevent its expansion.
>>>>>>> [And the "Commons" project's (with the word "project" as in "an
>>>>>>> Apache project") community certainly does not benefit from a
>>>>>>> pool of contributors commensurate with its purported goal and
>>>>>>> user base.]
>>>>>>>
>>>>>>> On the practical side, I'm not (yet) against having a single "dev"
>>>>>>> list: discussions about design are usually interesting even if
>>>>>>> applied to another project's codebase (with the the word "project"
>>>>>>> as in "programming project").
>>>>>>>
>>>>>>> But lately, the flood of automatic notifications (commits and CI)
>>>>>>> has drowned the useful discussions.
>>>>>>>
>>>>>> commits are already sent to a separate list.
>>>>>>
>>>>> The more stringent problem is getting _all_ the projects' commits!
>>>>>
>>>>> I have just recently changed Continuum and the Jenkins Math job to use
>>>>>> commits as well.
>>>>>>
>>>>>> What other automatic notifications are still affecting the dev list?
>>>>>>
>>>>>> Maybe they can be redirected elsewhere.
>>>>>>
>>>>>> For people who do not contribute to a project (i.e. neither
>>>>>>> providing code nor checking it), a commit diff is just noise
>>>>>>> because they lack context (not being aquainted with the codebase).
>>>>>>>
>>>>>> Indeed, which is why it is good that they are sent to a different
>>>>>> mailing list.
>>>>>>
>>>>> Good, yes. Enough, no.
>>>>>
>>>>>
>>>>>> The Commons community's implied answer to the stated fact is
>>>>>>> that people who feel that way should change their perception of
>>>>>>> reality, or go away.
>>>>>>>
>>>>>>> The respectful answer would be to solve the problem with the
>>>>>>> readily available technology of the 1990s: separate MLs for
>>>>>>> each project's _notifications_ (with the word "project" as in
>>>>>>> "programming project").
>>>>>>>
>>>>>> As already previously noted, the PMC are responsible for oversight and
>>>>>> so must see all the commits.
>>>>>>
>>>>> No, they _must_ not. Because you cannot enforce the "must". [As noted
>>>>> by several people, they use filters...]
>>>>> People do what they want, and what they can.
>>>>>
>>>> In addition to segregated commit MLs, I think that one _digest_ message
>>>> every day, summarizing all the commits (of all projects) of the day might
>>>> help a lot: policy would be safe.
>>>>
>>>>
>>>> Gilles
>>>>
>>>>
>>>> The number of people voting for any one release of a given
>>>>> (programming) project is proof enough that not everybody checks
>>>>> everything.
>>>>> Even those who vote "should" review, but not necessarily do so
>>>>> extensively (if, for example, what is more important for them is
>>>>> that the release happens).
>>>>> [To avoid instant flaming, I immediately stress that it is _not_
>>>>> to say that Apache should publish unreviewed code...]
>>>>>
>>>>> Would it really make enough of a difference to non-PMC members to be
>>>>>> worth the additional work (ours and Infra) of setting up individual
>>>>>> commit lists?
>>>>>>
>>>>> The result would be worth it; oh, yes!
>>>>>
>>>>> Unfortunately, I cannot imagine how much work this is going to be,
>>>>> as I never delved into commit trigger scripts.
>>>>>
>>>>>
>>>>> Gilles
>>>>>
>>>>>
>>>>>>> Regards,
>>>>>>> Gilles
>>>>>>>
>>>>>>>
>>>>>>> Ole
>>>>>>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>>>>>
>>>>>>>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>>>>>>>> something like Google Groups where I can set my notification
>>>>>>>>> preferences
>>>>>>>>> easily to send me updates only on certain threads such as threads I've
>>>>>>>>> started, which has a nice easily browsable and searchable web
>>>>>>>>> interface,
>>>>>>>>> and where I do not have to go through a signup process for each new
>>>>>>>>> group/list I want to post to. I feel many of the problems folks are
>>>>>>>>> talking
>>>>>>>>> about here are caused by using a frustrating technology. E.g. it was
>>>>>>>>> mentioned that if we split mailing lists that joining every list
>>>>>>>>> would be
>>>>>>>>> very painful. Perhaps that's because the process of joining just a
>>>>>>>>> single
>>>>>>>>> list is too difficult. Having to setup filters is also not very
>>>>>>>>> user-friendly. How do I make a filter that says only put threads on
>>>>>>>>> which
>>>>>>>>> I've participated in my inbox? There's probably a way, but it's not as
>>>>>>>>> obvious as clicking a single button. And even with filters I still
>>>>>>>>> don't
>>>>>>>>> want most of this garbage coming to my mail account anyway because it
>>>>>>>>> pollutes my search results when I'm looking for something I do care
>>>>>>>>> about.
>>>>>>>>> I signed up for the dev list just so that I could ask that someone
>>>>>>>>> reviews
>>>>>>>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>>>>>>>> (which
>>>>>>>>> I still need help with), but I really have no interest in getting any
>>>>>>>>> commons mail beyond that. I've never participated in any of these
>>>>>>>>> other
>>>>>>>>> projects and flooding my inbox is just frustrating and isn't going to
>>>>>>>>> cause
>>>>>>>>> me to start. The web interface for mailing list archives is truly
>>>>>>>>> horrendous.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gilles@harfang.homelinux.org
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>>>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>>>>>>>> ML they see fit?
>>>>>>>>>>>>
>>>>>>>>>>>> You missed my point - but never mind.
>>>>>>>>>>> What was it?
>>>>>>>>>> Judging from your comments below, you completely missed mine.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>>>>>>>>> components.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> I'm not talking about the size of components, but the size of the
>>>>>>>>>>>> ML traffic.
>>>>>>>>>>>>
>>>>>>>>>>>> So just because a component/project has a lot of ML traffic you
>>>>>>>>>>> want
>>>>>>>>>>> to make it TLP?
>>>>>>>>>>>
>>>>>>>>>>> I never said that.
>>>>>>>>>> I'm only complaining about ML traffic.
>>>>>>>>>>
>>>>>>>>>> Usually it should be about having enough active committers and
>>>>>>>>>> users.
>>>>>>>>>>
>>>>>>>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>>>>>>>> mean the same.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've never a great fan of umbrellas but the components are so
>>>>>>>>>>> small -
>>>>>>>>>>>
>>>>>>>>>>>>> I don't see another option. The thought of components to go TLP
>>>>>>>>>>>>> feels
>>>>>>>>>>>>> just plain silly to me. Hence it would be great to work together
>>>>>>>>>>>>> as a
>>>>>>>>>>>>> community that takes care of those components.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>>>>>>>>> accept
>>>>>>>>>>>> silly things that result from history (and consider the practical
>>>>>>>>>>>> advantages, as I noted elsewhere).
>>>>>>>>>>>>
>>>>>>>>>>>> Well, by the current definition it's not an Apache project. Call
>>>>>>>>>>> it
>>>>>>>>>>> sub-project if you like - I don't care.
>>>>>>>>>>>
>>>>>>>>>>> What I'm calling "project" is a _programming_ project; that's the
>>>>>>>>>> word
>>>>>>>>>> I'm used to; do you have another one?
>>>>>>>>>> Every component is a separate programming project, it's a simple
>>>>>>>>>> fact.
>>>>>>>>>>
>>>>>>>>>> At some stage we decided to call it component. After all I see it
>>>>>>>>>> as
>>>>>>>>>>
>>>>>>>>>>> a library.
>>>>>>>>>>>
>>>>>>>>>>> Do you think it's more and needs to be raised to the level to full
>>>>>>>>>>> blown project like hadoop or httpd?
>>>>>>>>>>> Not sure it Math holds that comparison but you are welcome to
>>>>>>>>>>> convince
>>>>>>>>>>> us.
>>>>>>>>>>>
>>>>>>>>>>> I think that this has nothing to do with this thread.
>>>>>>>>>>
>>>>>>>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>>>>>>>> community" is not very developed...
>>>>>>>>>>>>
>>>>>>>>>>>> And that's what I call an oversimplification.
>>>>>>>>>>>
>>>>>>>>>>> You brought that up (one community == one list). Or another missed
>>>>>>>>>> point?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Phil Steitz <ph...@gmail.com>.
On 1/17/15 3:11 PM, sebb wrote:
> On 17 January 2015 at 16:29, Mark Fortner <ph...@gmail.com> wrote:
>> Bulk JIRA changes prior to a release tend to swamp the list. Perhaps it
>> would be better to close the issue as the work is done.
> The convention is to resolve the issue when the work is done and close
> the issues after the release.
>
> When bulk closing lots of issues, it's easy enough to suppress the email.
How, exactly? I used to be able to do this, but I don't seem to
have the karma now or maybe I just forgot how.
Sorry for the hijack; but I agree this is noise that would be nice
to suppress.
The website commits are another morass. I find that when I do it
"manually" - command line checkin as opposed to counting on the
maven site thingy - there is often much less noise. Is there a way
to do that "silently" as well?
Phil
>
>> Mark
>> On Jan 17, 2015 8:11 AM, "Gilles" <gi...@harfang.homelinux.org> wrote:
>>
>>> On Sat, 17 Jan 2015 16:36:55 +0100, Gilles wrote:
>>>
>>>> On Sat, 17 Jan 2015 15:00:34 +0000, sebb wrote:
>>>>
>>>>> On 17 January 2015 at 14:23, Gilles <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>>>>
>>>>>>> I agree - we're hung up on a clown from the 90s. It's so much
>>>>>>> simpler click watch on github and get notifications. Also
>>>>>>> stackoverflow has a much broader Java community and having traffic go
>>>>>>> through it could benefit this community.
>>>>>>>
>>>>>>
>>>>>> I'm afraid that the main problem is not the tool.
>>>>>>
>>>>>> Step 1: an issue is felt as a problem by some people (from the
>>>>>> community or might-be contributors)
>>>>>> Step 2: people (from the community) who don't feel the problem
>>>>>> try to demonstrate that there isn't a problem, thus
>>>>>> dismissing the (argumented) feeling of others
>>>>>>
>>>>>> This can destroy a community, or at least prevent its expansion.
>>>>>> [And the "Commons" project's (with the word "project" as in "an
>>>>>> Apache project") community certainly does not benefit from a
>>>>>> pool of contributors commensurate with its purported goal and
>>>>>> user base.]
>>>>>>
>>>>>> On the practical side, I'm not (yet) against having a single "dev"
>>>>>> list: discussions about design are usually interesting even if
>>>>>> applied to another project's codebase (with the the word "project"
>>>>>> as in "programming project").
>>>>>>
>>>>>> But lately, the flood of automatic notifications (commits and CI)
>>>>>> has drowned the useful discussions.
>>>>>>
>>>>> commits are already sent to a separate list.
>>>>>
>>>> The more stringent problem is getting _all_ the projects' commits!
>>>>
>>>> I have just recently changed Continuum and the Jenkins Math job to use
>>>>> commits as well.
>>>>>
>>>>> What other automatic notifications are still affecting the dev list?
>>>>>
>>>>> Maybe they can be redirected elsewhere.
>>>>>
>>>>> For people who do not contribute to a project (i.e. neither
>>>>>> providing code nor checking it), a commit diff is just noise
>>>>>> because they lack context (not being aquainted with the codebase).
>>>>>>
>>>>> Indeed, which is why it is good that they are sent to a different
>>>>> mailing list.
>>>>>
>>>> Good, yes. Enough, no.
>>>>
>>>>
>>>>> The Commons community's implied answer to the stated fact is
>>>>>> that people who feel that way should change their perception of
>>>>>> reality, or go away.
>>>>>>
>>>>>> The respectful answer would be to solve the problem with the
>>>>>> readily available technology of the 1990s: separate MLs for
>>>>>> each project's _notifications_ (with the word "project" as in
>>>>>> "programming project").
>>>>>>
>>>>> As already previously noted, the PMC are responsible for oversight and
>>>>> so must see all the commits.
>>>>>
>>>> No, they _must_ not. Because you cannot enforce the "must". [As noted
>>>> by several people, they use filters...]
>>>> People do what they want, and what they can.
>>>>
>>> In addition to segregated commit MLs, I think that one _digest_ message
>>> every day, summarizing all the commits (of all projects) of the day might
>>> help a lot: policy would be safe.
>>>
>>>
>>> Gilles
>>>
>>>
>>> The number of people voting for any one release of a given
>>>> (programming) project is proof enough that not everybody checks
>>>> everything.
>>>> Even those who vote "should" review, but not necessarily do so
>>>> extensively (if, for example, what is more important for them is
>>>> that the release happens).
>>>> [To avoid instant flaming, I immediately stress that it is _not_
>>>> to say that Apache should publish unreviewed code...]
>>>>
>>>> Would it really make enough of a difference to non-PMC members to be
>>>>> worth the additional work (ours and Infra) of setting up individual
>>>>> commit lists?
>>>>>
>>>> The result would be worth it; oh, yes!
>>>>
>>>> Unfortunately, I cannot imagine how much work this is going to be,
>>>> as I never delved into commit trigger scripts.
>>>>
>>>>
>>>> Gilles
>>>>
>>>>
>>>>>> Regards,
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>> Ole
>>>>>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>>>>
>>>>>>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>>>>>>> something like Google Groups where I can set my notification
>>>>>>>> preferences
>>>>>>>> easily to send me updates only on certain threads such as threads I've
>>>>>>>> started, which has a nice easily browsable and searchable web
>>>>>>>> interface,
>>>>>>>> and where I do not have to go through a signup process for each new
>>>>>>>> group/list I want to post to. I feel many of the problems folks are
>>>>>>>> talking
>>>>>>>> about here are caused by using a frustrating technology. E.g. it was
>>>>>>>> mentioned that if we split mailing lists that joining every list
>>>>>>>> would be
>>>>>>>> very painful. Perhaps that's because the process of joining just a
>>>>>>>> single
>>>>>>>> list is too difficult. Having to setup filters is also not very
>>>>>>>> user-friendly. How do I make a filter that says only put threads on
>>>>>>>> which
>>>>>>>> I've participated in my inbox? There's probably a way, but it's not as
>>>>>>>> obvious as clicking a single button. And even with filters I still
>>>>>>>> don't
>>>>>>>> want most of this garbage coming to my mail account anyway because it
>>>>>>>> pollutes my search results when I'm looking for something I do care
>>>>>>>> about.
>>>>>>>> I signed up for the dev list just so that I could ask that someone
>>>>>>>> reviews
>>>>>>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>>>>>>> (which
>>>>>>>> I still need help with), but I really have no interest in getting any
>>>>>>>> commons mail beyond that. I've never participated in any of these
>>>>>>>> other
>>>>>>>> projects and flooding my inbox is just frustrating and isn't going to
>>>>>>>> cause
>>>>>>>> me to start. The web interface for mailing list archives is truly
>>>>>>>> horrendous.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gilles@harfang.homelinux.org
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>>>>>>> ML they see fit?
>>>>>>>>>>>
>>>>>>>>>>> You missed my point - but never mind.
>>>>>>>>>> What was it?
>>>>>>>>> Judging from your comments below, you completely missed mine.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>>>>>>>> components.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I'm not talking about the size of components, but the size of the
>>>>>>>>>>> ML traffic.
>>>>>>>>>>>
>>>>>>>>>>> So just because a component/project has a lot of ML traffic you
>>>>>>>>>> want
>>>>>>>>>> to make it TLP?
>>>>>>>>>>
>>>>>>>>>> I never said that.
>>>>>>>>> I'm only complaining about ML traffic.
>>>>>>>>>
>>>>>>>>> Usually it should be about having enough active committers and
>>>>>>>>> users.
>>>>>>>>>
>>>>>>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>>>>>>> mean the same.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've never a great fan of umbrellas but the components are so
>>>>>>>>>> small -
>>>>>>>>>>
>>>>>>>>>>>> I don't see another option. The thought of components to go TLP
>>>>>>>>>>>> feels
>>>>>>>>>>>> just plain silly to me. Hence it would be great to work together
>>>>>>>>>>>> as a
>>>>>>>>>>>> community that takes care of those components.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>>>>>>>> accept
>>>>>>>>>>> silly things that result from history (and consider the practical
>>>>>>>>>>> advantages, as I noted elsewhere).
>>>>>>>>>>>
>>>>>>>>>>> Well, by the current definition it's not an Apache project. Call
>>>>>>>>>> it
>>>>>>>>>> sub-project if you like - I don't care.
>>>>>>>>>>
>>>>>>>>>> What I'm calling "project" is a _programming_ project; that's the
>>>>>>>>> word
>>>>>>>>> I'm used to; do you have another one?
>>>>>>>>> Every component is a separate programming project, it's a simple
>>>>>>>>> fact.
>>>>>>>>>
>>>>>>>>> At some stage we decided to call it component. After all I see it
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>>> a library.
>>>>>>>>>>
>>>>>>>>>> Do you think it's more and needs to be raised to the level to full
>>>>>>>>>> blown project like hadoop or httpd?
>>>>>>>>>> Not sure it Math holds that comparison but you are welcome to
>>>>>>>>>> convince
>>>>>>>>>> us.
>>>>>>>>>>
>>>>>>>>>> I think that this has nothing to do with this thread.
>>>>>>>>>
>>>>>>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>>>>>>> community" is not very developed...
>>>>>>>>>>>
>>>>>>>>>>> And that's what I call an oversimplification.
>>>>>>>>>>
>>>>>>>>>> You brought that up (one community == one list). Or another missed
>>>>>>>>> point?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by sebb <se...@gmail.com>.
On 17 January 2015 at 16:29, Mark Fortner <ph...@gmail.com> wrote:
> Bulk JIRA changes prior to a release tend to swamp the list. Perhaps it
> would be better to close the issue as the work is done.
The convention is to resolve the issue when the work is done and close
the issues after the release.
When bulk closing lots of issues, it's easy enough to suppress the email.
> Mark
> On Jan 17, 2015 8:11 AM, "Gilles" <gi...@harfang.homelinux.org> wrote:
>
>> On Sat, 17 Jan 2015 16:36:55 +0100, Gilles wrote:
>>
>>> On Sat, 17 Jan 2015 15:00:34 +0000, sebb wrote:
>>>
>>>> On 17 January 2015 at 14:23, Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>>>
>>>>>>
>>>>>> I agree - we're hung up on a clown from the 90s. It's so much
>>>>>> simpler click watch on github and get notifications. Also
>>>>>> stackoverflow has a much broader Java community and having traffic go
>>>>>> through it could benefit this community.
>>>>>>
>>>>>
>>>>>
>>>>> I'm afraid that the main problem is not the tool.
>>>>>
>>>>> Step 1: an issue is felt as a problem by some people (from the
>>>>> community or might-be contributors)
>>>>> Step 2: people (from the community) who don't feel the problem
>>>>> try to demonstrate that there isn't a problem, thus
>>>>> dismissing the (argumented) feeling of others
>>>>>
>>>>> This can destroy a community, or at least prevent its expansion.
>>>>> [And the "Commons" project's (with the word "project" as in "an
>>>>> Apache project") community certainly does not benefit from a
>>>>> pool of contributors commensurate with its purported goal and
>>>>> user base.]
>>>>>
>>>>> On the practical side, I'm not (yet) against having a single "dev"
>>>>> list: discussions about design are usually interesting even if
>>>>> applied to another project's codebase (with the the word "project"
>>>>> as in "programming project").
>>>>>
>>>>> But lately, the flood of automatic notifications (commits and CI)
>>>>> has drowned the useful discussions.
>>>>>
>>>>
>>>> commits are already sent to a separate list.
>>>>
>>>
>>> The more stringent problem is getting _all_ the projects' commits!
>>>
>>> I have just recently changed Continuum and the Jenkins Math job to use
>>>> commits as well.
>>>>
>>>> What other automatic notifications are still affecting the dev list?
>>>>
>>>> Maybe they can be redirected elsewhere.
>>>>
>>>> For people who do not contribute to a project (i.e. neither
>>>>> providing code nor checking it), a commit diff is just noise
>>>>> because they lack context (not being aquainted with the codebase).
>>>>>
>>>>
>>>> Indeed, which is why it is good that they are sent to a different
>>>> mailing list.
>>>>
>>>
>>> Good, yes. Enough, no.
>>>
>>>
>>>> The Commons community's implied answer to the stated fact is
>>>>> that people who feel that way should change their perception of
>>>>> reality, or go away.
>>>>>
>>>>> The respectful answer would be to solve the problem with the
>>>>> readily available technology of the 1990s: separate MLs for
>>>>> each project's _notifications_ (with the word "project" as in
>>>>> "programming project").
>>>>>
>>>>
>>>> As already previously noted, the PMC are responsible for oversight and
>>>> so must see all the commits.
>>>>
>>>
>>> No, they _must_ not. Because you cannot enforce the "must". [As noted
>>> by several people, they use filters...]
>>> People do what they want, and what they can.
>>>
>>
>> In addition to segregated commit MLs, I think that one _digest_ message
>> every day, summarizing all the commits (of all projects) of the day might
>> help a lot: policy would be safe.
>>
>>
>> Gilles
>>
>>
>> The number of people voting for any one release of a given
>>> (programming) project is proof enough that not everybody checks
>>> everything.
>>> Even those who vote "should" review, but not necessarily do so
>>> extensively (if, for example, what is more important for them is
>>> that the release happens).
>>> [To avoid instant flaming, I immediately stress that it is _not_
>>> to say that Apache should publish unreviewed code...]
>>>
>>> Would it really make enough of a difference to non-PMC members to be
>>>> worth the additional work (ours and Infra) of setting up individual
>>>> commit lists?
>>>>
>>>
>>> The result would be worth it; oh, yes!
>>>
>>> Unfortunately, I cannot imagine how much work this is going to be,
>>> as I never delved into commit trigger scripts.
>>>
>>>
>>> Gilles
>>>
>>>
>>>>> Regards,
>>>>> Gilles
>>>>>
>>>>>
>>>>> Ole
>>>>>>
>>>>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>>>
>>>>>>>
>>>>>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>>>>>> something like Google Groups where I can set my notification
>>>>>>> preferences
>>>>>>> easily to send me updates only on certain threads such as threads I've
>>>>>>> started, which has a nice easily browsable and searchable web
>>>>>>> interface,
>>>>>>> and where I do not have to go through a signup process for each new
>>>>>>> group/list I want to post to. I feel many of the problems folks are
>>>>>>> talking
>>>>>>> about here are caused by using a frustrating technology. E.g. it was
>>>>>>> mentioned that if we split mailing lists that joining every list
>>>>>>> would be
>>>>>>> very painful. Perhaps that's because the process of joining just a
>>>>>>> single
>>>>>>> list is too difficult. Having to setup filters is also not very
>>>>>>> user-friendly. How do I make a filter that says only put threads on
>>>>>>> which
>>>>>>> I've participated in my inbox? There's probably a way, but it's not as
>>>>>>> obvious as clicking a single button. And even with filters I still
>>>>>>> don't
>>>>>>> want most of this garbage coming to my mail account anyway because it
>>>>>>> pollutes my search results when I'm looking for something I do care
>>>>>>> about.
>>>>>>> I signed up for the dev list just so that I could ask that someone
>>>>>>> reviews
>>>>>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>>>>>> (which
>>>>>>> I still need help with), but I really have no interest in getting any
>>>>>>> commons mail beyond that. I've never participated in any of these
>>>>>>> other
>>>>>>> projects and flooding my inbox is just frustrating and isn't going to
>>>>>>> cause
>>>>>>> me to start. The web interface for mailing list archives is truly
>>>>>>> horrendous.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gilles@harfang.homelinux.org
>>>>>>> >
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>>>>
>>>>>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ML they see fit?
>>>>>>>>>>
>>>>>>>>>> You missed my point - but never mind.
>>>>>>>>>
>>>>>>>>> What was it?
>>>>>>>>
>>>>>>>> Judging from your comments below, you completely missed mine.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> components.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I'm not talking about the size of components, but the size of the
>>>>>>>>>> ML traffic.
>>>>>>>>>>
>>>>>>>>>> So just because a component/project has a lot of ML traffic you
>>>>>>>>> want
>>>>>>>>> to make it TLP?
>>>>>>>>>
>>>>>>>>> I never said that.
>>>>>>>> I'm only complaining about ML traffic.
>>>>>>>>
>>>>>>>> Usually it should be about having enough active committers and
>>>>>>>> users.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>>>>>> mean the same.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've never a great fan of umbrellas but the components are so
>>>>>>>>> small -
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I don't see another option. The thought of components to go TLP
>>>>>>>>>>> feels
>>>>>>>>>>> just plain silly to me. Hence it would be great to work together
>>>>>>>>>>> as a
>>>>>>>>>>> community that takes care of those components.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>>>>>>> accept
>>>>>>>>>> silly things that result from history (and consider the practical
>>>>>>>>>> advantages, as I noted elsewhere).
>>>>>>>>>>
>>>>>>>>>> Well, by the current definition it's not an Apache project. Call
>>>>>>>>> it
>>>>>>>>> sub-project if you like - I don't care.
>>>>>>>>>
>>>>>>>>> What I'm calling "project" is a _programming_ project; that's the
>>>>>>>> word
>>>>>>>> I'm used to; do you have another one?
>>>>>>>> Every component is a separate programming project, it's a simple
>>>>>>>> fact.
>>>>>>>>
>>>>>>>> At some stage we decided to call it component. After all I see it
>>>>>>>> as
>>>>>>>>
>>>>>>>>>
>>>>>>>>> a library.
>>>>>>>>>
>>>>>>>>> Do you think it's more and needs to be raised to the level to full
>>>>>>>>> blown project like hadoop or httpd?
>>>>>>>>> Not sure it Math holds that comparison but you are welcome to
>>>>>>>>> convince
>>>>>>>>> us.
>>>>>>>>>
>>>>>>>>> I think that this has nothing to do with this thread.
>>>>>>>>
>>>>>>>>
>>>>>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> community" is not very developed...
>>>>>>>>>>
>>>>>>>>>> And that's what I call an oversimplification.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You brought that up (one community == one list). Or another missed
>>>>>>>> point?
>>>>>>>>
>>>>>>>>
>>>>>>>> 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: [ALL] Too much traffic on the "dev" ML
Posted by Mark Fortner <ph...@gmail.com>.
Bulk JIRA changes prior to a release tend to swamp the list. Perhaps it
would be better to close the issue as the work is done.
Mark
On Jan 17, 2015 8:11 AM, "Gilles" <gi...@harfang.homelinux.org> wrote:
> On Sat, 17 Jan 2015 16:36:55 +0100, Gilles wrote:
>
>> On Sat, 17 Jan 2015 15:00:34 +0000, sebb wrote:
>>
>>> On 17 January 2015 at 14:23, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>>
>>>>>
>>>>> I agree - we're hung up on a clown from the 90s. It's so much
>>>>> simpler click watch on github and get notifications. Also
>>>>> stackoverflow has a much broader Java community and having traffic go
>>>>> through it could benefit this community.
>>>>>
>>>>
>>>>
>>>> I'm afraid that the main problem is not the tool.
>>>>
>>>> Step 1: an issue is felt as a problem by some people (from the
>>>> community or might-be contributors)
>>>> Step 2: people (from the community) who don't feel the problem
>>>> try to demonstrate that there isn't a problem, thus
>>>> dismissing the (argumented) feeling of others
>>>>
>>>> This can destroy a community, or at least prevent its expansion.
>>>> [And the "Commons" project's (with the word "project" as in "an
>>>> Apache project") community certainly does not benefit from a
>>>> pool of contributors commensurate with its purported goal and
>>>> user base.]
>>>>
>>>> On the practical side, I'm not (yet) against having a single "dev"
>>>> list: discussions about design are usually interesting even if
>>>> applied to another project's codebase (with the the word "project"
>>>> as in "programming project").
>>>>
>>>> But lately, the flood of automatic notifications (commits and CI)
>>>> has drowned the useful discussions.
>>>>
>>>
>>> commits are already sent to a separate list.
>>>
>>
>> The more stringent problem is getting _all_ the projects' commits!
>>
>> I have just recently changed Continuum and the Jenkins Math job to use
>>> commits as well.
>>>
>>> What other automatic notifications are still affecting the dev list?
>>>
>>> Maybe they can be redirected elsewhere.
>>>
>>> For people who do not contribute to a project (i.e. neither
>>>> providing code nor checking it), a commit diff is just noise
>>>> because they lack context (not being aquainted with the codebase).
>>>>
>>>
>>> Indeed, which is why it is good that they are sent to a different
>>> mailing list.
>>>
>>
>> Good, yes. Enough, no.
>>
>>
>>> The Commons community's implied answer to the stated fact is
>>>> that people who feel that way should change their perception of
>>>> reality, or go away.
>>>>
>>>> The respectful answer would be to solve the problem with the
>>>> readily available technology of the 1990s: separate MLs for
>>>> each project's _notifications_ (with the word "project" as in
>>>> "programming project").
>>>>
>>>
>>> As already previously noted, the PMC are responsible for oversight and
>>> so must see all the commits.
>>>
>>
>> No, they _must_ not. Because you cannot enforce the "must". [As noted
>> by several people, they use filters...]
>> People do what they want, and what they can.
>>
>
> In addition to segregated commit MLs, I think that one _digest_ message
> every day, summarizing all the commits (of all projects) of the day might
> help a lot: policy would be safe.
>
>
> Gilles
>
>
> The number of people voting for any one release of a given
>> (programming) project is proof enough that not everybody checks
>> everything.
>> Even those who vote "should" review, but not necessarily do so
>> extensively (if, for example, what is more important for them is
>> that the release happens).
>> [To avoid instant flaming, I immediately stress that it is _not_
>> to say that Apache should publish unreviewed code...]
>>
>> Would it really make enough of a difference to non-PMC members to be
>>> worth the additional work (ours and Infra) of setting up individual
>>> commit lists?
>>>
>>
>> The result would be worth it; oh, yes!
>>
>> Unfortunately, I cannot imagine how much work this is going to be,
>> as I never delved into commit trigger scripts.
>>
>>
>> Gilles
>>
>>
>>>> Regards,
>>>> Gilles
>>>>
>>>>
>>>> Ole
>>>>>
>>>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>>
>>>>>>
>>>>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>>>>> something like Google Groups where I can set my notification
>>>>>> preferences
>>>>>> easily to send me updates only on certain threads such as threads I've
>>>>>> started, which has a nice easily browsable and searchable web
>>>>>> interface,
>>>>>> and where I do not have to go through a signup process for each new
>>>>>> group/list I want to post to. I feel many of the problems folks are
>>>>>> talking
>>>>>> about here are caused by using a frustrating technology. E.g. it was
>>>>>> mentioned that if we split mailing lists that joining every list
>>>>>> would be
>>>>>> very painful. Perhaps that's because the process of joining just a
>>>>>> single
>>>>>> list is too difficult. Having to setup filters is also not very
>>>>>> user-friendly. How do I make a filter that says only put threads on
>>>>>> which
>>>>>> I've participated in my inbox? There's probably a way, but it's not as
>>>>>> obvious as clicking a single button. And even with filters I still
>>>>>> don't
>>>>>> want most of this garbage coming to my mail account anyway because it
>>>>>> pollutes my search results when I'm looking for something I do care
>>>>>> about.
>>>>>> I signed up for the dev list just so that I could ask that someone
>>>>>> reviews
>>>>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>>>>> (which
>>>>>> I still need help with), but I really have no interest in getting any
>>>>>> commons mail beyond that. I've never participated in any of these
>>>>>> other
>>>>>> projects and flooding my inbox is just frustrating and isn't going to
>>>>>> cause
>>>>>> me to start. The web interface for mailing list archives is truly
>>>>>> horrendous.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gilles@harfang.homelinux.org
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>>>
>>>>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>>>>
>>>>>>>>>
>>>>>>>>> ML they see fit?
>>>>>>>>>
>>>>>>>>> You missed my point - but never mind.
>>>>>>>>
>>>>>>>> What was it?
>>>>>>>
>>>>>>> Judging from your comments below, you completely missed mine.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> components.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I'm not talking about the size of components, but the size of the
>>>>>>>>> ML traffic.
>>>>>>>>>
>>>>>>>>> So just because a component/project has a lot of ML traffic you
>>>>>>>> want
>>>>>>>> to make it TLP?
>>>>>>>>
>>>>>>>> I never said that.
>>>>>>> I'm only complaining about ML traffic.
>>>>>>>
>>>>>>> Usually it should be about having enough active committers and
>>>>>>> users.
>>>>>>>
>>>>>>>>
>>>>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>>>>> mean the same.
>>>>>>>>
>>>>>>>>
>>>>>>>> I've never a great fan of umbrellas but the components are so
>>>>>>>> small -
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I don't see another option. The thought of components to go TLP
>>>>>>>>>> feels
>>>>>>>>>> just plain silly to me. Hence it would be great to work together
>>>>>>>>>> as a
>>>>>>>>>> community that takes care of those components.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>>>>>> accept
>>>>>>>>> silly things that result from history (and consider the practical
>>>>>>>>> advantages, as I noted elsewhere).
>>>>>>>>>
>>>>>>>>> Well, by the current definition it's not an Apache project. Call
>>>>>>>> it
>>>>>>>> sub-project if you like - I don't care.
>>>>>>>>
>>>>>>>> What I'm calling "project" is a _programming_ project; that's the
>>>>>>> word
>>>>>>> I'm used to; do you have another one?
>>>>>>> Every component is a separate programming project, it's a simple
>>>>>>> fact.
>>>>>>>
>>>>>>> At some stage we decided to call it component. After all I see it
>>>>>>> as
>>>>>>>
>>>>>>>>
>>>>>>>> a library.
>>>>>>>>
>>>>>>>> Do you think it's more and needs to be raised to the level to full
>>>>>>>> blown project like hadoop or httpd?
>>>>>>>> Not sure it Math holds that comparison but you are welcome to
>>>>>>>> convince
>>>>>>>> us.
>>>>>>>>
>>>>>>>> I think that this has nothing to do with this thread.
>>>>>>>
>>>>>>>
>>>>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>>>>
>>>>>>>>>
>>>>>>>>> community" is not very developed...
>>>>>>>>>
>>>>>>>>> And that's what I call an oversimplification.
>>>>>>>>
>>>>>>>>
>>>>>>>> You brought that up (one community == one list). Or another missed
>>>>>>> point?
>>>>>>>
>>>>>>>
>>>>>>> Gilles
>>>>>>>
>>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sat, 17 Jan 2015 16:36:55 +0100, Gilles wrote:
> On Sat, 17 Jan 2015 15:00:34 +0000, sebb wrote:
>> On 17 January 2015 at 14:23, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>>
>>>> I agree - we're hung up on a clown from the 90s. It's so much
>>>> simpler click watch on github and get notifications. Also
>>>> stackoverflow has a much broader Java community and having traffic
>>>> go
>>>> through it could benefit this community.
>>>
>>>
>>> I'm afraid that the main problem is not the tool.
>>>
>>> Step 1: an issue is felt as a problem by some people (from the
>>> community or might-be contributors)
>>> Step 2: people (from the community) who don't feel the problem
>>> try to demonstrate that there isn't a problem, thus
>>> dismissing the (argumented) feeling of others
>>>
>>> This can destroy a community, or at least prevent its expansion.
>>> [And the "Commons" project's (with the word "project" as in "an
>>> Apache project") community certainly does not benefit from a
>>> pool of contributors commensurate with its purported goal and
>>> user base.]
>>>
>>> On the practical side, I'm not (yet) against having a single "dev"
>>> list: discussions about design are usually interesting even if
>>> applied to another project's codebase (with the the word "project"
>>> as in "programming project").
>>>
>>> But lately, the flood of automatic notifications (commits and CI)
>>> has drowned the useful discussions.
>>
>> commits are already sent to a separate list.
>
> The more stringent problem is getting _all_ the projects' commits!
>
>> I have just recently changed Continuum and the Jenkins Math job to
>> use
>> commits as well.
>>
>> What other automatic notifications are still affecting the dev list?
>>
>> Maybe they can be redirected elsewhere.
>>
>>> For people who do not contribute to a project (i.e. neither
>>> providing code nor checking it), a commit diff is just noise
>>> because they lack context (not being aquainted with the codebase).
>>
>> Indeed, which is why it is good that they are sent to a different
>> mailing list.
>
> Good, yes. Enough, no.
>
>>
>>> The Commons community's implied answer to the stated fact is
>>> that people who feel that way should change their perception of
>>> reality, or go away.
>>>
>>> The respectful answer would be to solve the problem with the
>>> readily available technology of the 1990s: separate MLs for
>>> each project's _notifications_ (with the word "project" as in
>>> "programming project").
>>
>> As already previously noted, the PMC are responsible for oversight
>> and
>> so must see all the commits.
>
> No, they _must_ not. Because you cannot enforce the "must". [As noted
> by several people, they use filters...]
> People do what they want, and what they can.
In addition to segregated commit MLs, I think that one _digest_ message
every day, summarizing all the commits (of all projects) of the day
might
help a lot: policy would be safe.
Gilles
> The number of people voting for any one release of a given
> (programming) project is proof enough that not everybody checks
> everything.
> Even those who vote "should" review, but not necessarily do so
> extensively (if, for example, what is more important for them is
> that the release happens).
> [To avoid instant flaming, I immediately stress that it is _not_
> to say that Apache should publish unreviewed code...]
>
>> Would it really make enough of a difference to non-PMC members to be
>> worth the additional work (ours and Infra) of setting up individual
>> commit lists?
>
> The result would be worth it; oh, yes!
>
> Unfortunately, I cannot imagine how much work this is going to be,
> as I never delved into commit trigger scripts.
>
>
> Gilles
>
>>>
>>> Regards,
>>> Gilles
>>>
>>>
>>>> Ole
>>>>
>>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>>
>>>>> I find the whole I idea of a mailing list very 1990s. I'd much
>>>>> prefer
>>>>> something like Google Groups where I can set my notification
>>>>> preferences
>>>>> easily to send me updates only on certain threads such as threads
>>>>> I've
>>>>> started, which has a nice easily browsable and searchable web
>>>>> interface,
>>>>> and where I do not have to go through a signup process for each
>>>>> new
>>>>> group/list I want to post to. I feel many of the problems folks
>>>>> are
>>>>> talking
>>>>> about here are caused by using a frustrating technology. E.g. it
>>>>> was
>>>>> mentioned that if we split mailing lists that joining every list
>>>>> would be
>>>>> very painful. Perhaps that's because the process of joining just
>>>>> a single
>>>>> list is too difficult. Having to setup filters is also not very
>>>>> user-friendly. How do I make a filter that says only put threads
>>>>> on which
>>>>> I've participated in my inbox? There's probably a way, but it's
>>>>> not as
>>>>> obvious as clicking a single button. And even with filters I
>>>>> still don't
>>>>> want most of this garbage coming to my mail account anyway
>>>>> because it
>>>>> pollutes my search results when I'm looking for something I do
>>>>> care
>>>>> about.
>>>>> I signed up for the dev list just so that I could ask that
>>>>> someone
>>>>> reviews
>>>>> and commits my patch
>>>>> <https://issues.apache.org/jira/browse/BCEL-186>
>>>>> (which
>>>>> I still need help with), but I really have no interest in getting
>>>>> any
>>>>> commons mail beyond that. I've never participated in any of these
>>>>> other
>>>>> projects and flooding my inbox is just frustrating and isn't
>>>>> going to
>>>>> cause
>>>>> me to start. The web interface for mailing list archives is truly
>>>>> horrendous.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles
>>>>> <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>>
>>>>>>> Was it mentioned that anybody would be forbidden to subscribe
>>>>>>> to any
>>>>>>>>
>>>>>>>> ML they see fit?
>>>>>>>>
>>>>>>> You missed my point - but never mind.
>>>>>>>
>>>>>> What was it?
>>>>>>
>>>>>> Judging from your comments below, you completely missed mine.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> That comparison is pretty flawed as those projects are not
>>>>>>> tiny
>>>>>>>>>
>>>>>>>>> components.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not talking about the size of components, but the size of
>>>>>>>> the
>>>>>>>> ML traffic.
>>>>>>>>
>>>>>>> So just because a component/project has a lot of ML traffic you
>>>>>>> want
>>>>>>> to make it TLP?
>>>>>>>
>>>>>> I never said that.
>>>>>> I'm only complaining about ML traffic.
>>>>>>
>>>>>> Usually it should be about having enough active committers and
>>>>>> users.
>>>>>>>
>>>>>>> While this might contribute to ML traffic, it doesn't
>>>>>>> necessarily
>>>>>>> mean the same.
>>>>>>>
>>>>>>>
>>>>>>> I've never a great fan of umbrellas but the components are so
>>>>>>> small -
>>>>>>>>>
>>>>>>>>> I don't see another option. The thought of components to go
>>>>>>>>> TLP feels
>>>>>>>>> just plain silly to me. Hence it would be great to work
>>>>>>>>> together as a
>>>>>>>>> community that takes care of those components.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The idea of "Commons Math" being a component is silly, but we
>>>>>>>> can
>>>>>>>> accept
>>>>>>>> silly things that result from history (and consider the
>>>>>>>> practical
>>>>>>>> advantages, as I noted elsewhere).
>>>>>>>>
>>>>>>> Well, by the current definition it's not an Apache project.
>>>>>>> Call it
>>>>>>> sub-project if you like - I don't care.
>>>>>>>
>>>>>> What I'm calling "project" is a _programming_ project; that's
>>>>>> the word
>>>>>> I'm used to; do you have another one?
>>>>>> Every component is a separate programming project, it's a simple
>>>>>> fact.
>>>>>>
>>>>>> At some stage we decided to call it component. After all I see
>>>>>> it as
>>>>>>>
>>>>>>> a library.
>>>>>>>
>>>>>>> Do you think it's more and needs to be raised to the level to
>>>>>>> full
>>>>>>> blown project like hadoop or httpd?
>>>>>>> Not sure it Math holds that comparison but you are welcome to
>>>>>>> convince
>>>>>>> us.
>>>>>>>
>>>>>> I think that this has nothing to do with this thread.
>>>>>>
>>>>>>
>>>>>>> If it depends on the name of the list, I guess that the
>>>>>>> "sense of
>>>>>>>>
>>>>>>>> community" is not very developed...
>>>>>>>>
>>>>>>> And that's what I call an oversimplification.
>>>>>>>
>>>>>>>
>>>>>> You brought that up (one community == one list). Or another
>>>>>> missed
>>>>>> point?
>>>>>>
>>>>>>
>>>>>> Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sat, 17 Jan 2015 15:00:34 +0000, sebb wrote:
> On 17 January 2015 at 14:23, Gilles <gi...@harfang.homelinux.org>
> wrote:
>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>
>>> I agree - we're hung up on a clown from the 90s. It's so much
>>> simpler click watch on github and get notifications. Also
>>> stackoverflow has a much broader Java community and having traffic
>>> go
>>> through it could benefit this community.
>>
>>
>> I'm afraid that the main problem is not the tool.
>>
>> Step 1: an issue is felt as a problem by some people (from the
>> community or might-be contributors)
>> Step 2: people (from the community) who don't feel the problem
>> try to demonstrate that there isn't a problem, thus
>> dismissing the (argumented) feeling of others
>>
>> This can destroy a community, or at least prevent its expansion.
>> [And the "Commons" project's (with the word "project" as in "an
>> Apache project") community certainly does not benefit from a
>> pool of contributors commensurate with its purported goal and
>> user base.]
>>
>> On the practical side, I'm not (yet) against having a single "dev"
>> list: discussions about design are usually interesting even if
>> applied to another project's codebase (with the the word "project"
>> as in "programming project").
>>
>> But lately, the flood of automatic notifications (commits and CI)
>> has drowned the useful discussions.
>
> commits are already sent to a separate list.
The more stringent problem is getting _all_ the projects' commits!
> I have just recently changed Continuum and the Jenkins Math job to
> use
> commits as well.
>
> What other automatic notifications are still affecting the dev list?
>
> Maybe they can be redirected elsewhere.
>
>> For people who do not contribute to a project (i.e. neither
>> providing code nor checking it), a commit diff is just noise
>> because they lack context (not being aquainted with the codebase).
>
> Indeed, which is why it is good that they are sent to a different
> mailing list.
Good, yes. Enough, no.
>
>> The Commons community's implied answer to the stated fact is
>> that people who feel that way should change their perception of
>> reality, or go away.
>>
>> The respectful answer would be to solve the problem with the
>> readily available technology of the 1990s: separate MLs for
>> each project's _notifications_ (with the word "project" as in
>> "programming project").
>
> As already previously noted, the PMC are responsible for oversight
> and
> so must see all the commits.
No, they _must_ not. Because you cannot enforce the "must". [As noted
by several people, they use filters...]
People do what they want, and what they can.
The number of people voting for any one release of a given
(programming) project is proof enough that not everybody checks
everything.
Even those who vote "should" review, but not necessarily do so
extensively (if, for example, what is more important for them is
that the release happens).
[To avoid instant flaming, I immediately stress that it is _not_
to say that Apache should publish unreviewed code...]
> Would it really make enough of a difference to non-PMC members to be
> worth the additional work (ours and Infra) of setting up individual
> commit lists?
The result would be worth it; oh, yes!
Unfortunately, I cannot imagine how much work this is going to be,
as I never delved into commit trigger scripts.
Gilles
>>
>> Regards,
>> Gilles
>>
>>
>>> Ole
>>>
>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>
>>>> I find the whole I idea of a mailing list very 1990s. I'd much
>>>> prefer
>>>> something like Google Groups where I can set my notification
>>>> preferences
>>>> easily to send me updates only on certain threads such as threads
>>>> I've
>>>> started, which has a nice easily browsable and searchable web
>>>> interface,
>>>> and where I do not have to go through a signup process for each
>>>> new
>>>> group/list I want to post to. I feel many of the problems folks
>>>> are
>>>> talking
>>>> about here are caused by using a frustrating technology. E.g. it
>>>> was
>>>> mentioned that if we split mailing lists that joining every list
>>>> would be
>>>> very painful. Perhaps that's because the process of joining just a
>>>> single
>>>> list is too difficult. Having to setup filters is also not very
>>>> user-friendly. How do I make a filter that says only put threads
>>>> on which
>>>> I've participated in my inbox? There's probably a way, but it's
>>>> not as
>>>> obvious as clicking a single button. And even with filters I still
>>>> don't
>>>> want most of this garbage coming to my mail account anyway because
>>>> it
>>>> pollutes my search results when I'm looking for something I do
>>>> care
>>>> about.
>>>> I signed up for the dev list just so that I could ask that someone
>>>> reviews
>>>> and commits my patch
>>>> <https://issues.apache.org/jira/browse/BCEL-186>
>>>> (which
>>>> I still need help with), but I really have no interest in getting
>>>> any
>>>> commons mail beyond that. I've never participated in any of these
>>>> other
>>>> projects and flooding my inbox is just frustrating and isn't going
>>>> to
>>>> cause
>>>> me to start. The web interface for mailing list archives is truly
>>>> horrendous.
>>>>
>>>>
>>>>
>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles
>>>> <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>
>>>>>> Was it mentioned that anybody would be forbidden to subscribe to
>>>>>> any
>>>>>>>
>>>>>>> ML they see fit?
>>>>>>>
>>>>>> You missed my point - but never mind.
>>>>>>
>>>>> What was it?
>>>>>
>>>>> Judging from your comments below, you completely missed mine.
>>>>>
>>>>>
>>>>>
>>>>>> That comparison is pretty flawed as those projects are not
>>>>>> tiny
>>>>>>>>
>>>>>>>> components.
>>>>>>>>
>>>>>>>
>>>>>>> I'm not talking about the size of components, but the size of
>>>>>>> the
>>>>>>> ML traffic.
>>>>>>>
>>>>>> So just because a component/project has a lot of ML traffic you
>>>>>> want
>>>>>> to make it TLP?
>>>>>>
>>>>> I never said that.
>>>>> I'm only complaining about ML traffic.
>>>>>
>>>>> Usually it should be about having enough active committers and
>>>>> users.
>>>>>>
>>>>>> While this might contribute to ML traffic, it doesn't
>>>>>> necessarily
>>>>>> mean the same.
>>>>>>
>>>>>>
>>>>>> I've never a great fan of umbrellas but the components are so
>>>>>> small -
>>>>>>>>
>>>>>>>> I don't see another option. The thought of components to go
>>>>>>>> TLP feels
>>>>>>>> just plain silly to me. Hence it would be great to work
>>>>>>>> together as a
>>>>>>>> community that takes care of those components.
>>>>>>>>
>>>>>>>
>>>>>>> The idea of "Commons Math" being a component is silly, but we
>>>>>>> can
>>>>>>> accept
>>>>>>> silly things that result from history (and consider the
>>>>>>> practical
>>>>>>> advantages, as I noted elsewhere).
>>>>>>>
>>>>>> Well, by the current definition it's not an Apache project. Call
>>>>>> it
>>>>>> sub-project if you like - I don't care.
>>>>>>
>>>>> What I'm calling "project" is a _programming_ project; that's the
>>>>> word
>>>>> I'm used to; do you have another one?
>>>>> Every component is a separate programming project, it's a simple
>>>>> fact.
>>>>>
>>>>> At some stage we decided to call it component. After all I see
>>>>> it as
>>>>>>
>>>>>> a library.
>>>>>>
>>>>>> Do you think it's more and needs to be raised to the level to
>>>>>> full
>>>>>> blown project like hadoop or httpd?
>>>>>> Not sure it Math holds that comparison but you are welcome to
>>>>>> convince
>>>>>> us.
>>>>>>
>>>>> I think that this has nothing to do with this thread.
>>>>>
>>>>>
>>>>>> If it depends on the name of the list, I guess that the "sense
>>>>>> of
>>>>>>>
>>>>>>> community" is not very developed...
>>>>>>>
>>>>>> And that's what I call an oversimplification.
>>>>>>
>>>>>>
>>>>> You brought that up (one community == one list). Or another
>>>>> missed
>>>>> point?
>>>>>
>>>>>
>>>>> Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by sebb <se...@gmail.com>.
On 17 January 2015 at 14:23, Gilles <gi...@harfang.homelinux.org> wrote:
> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>
>> I agree - we're hung up on a clown from the 90s. It's so much
>> simpler click watch on github and get notifications. Also
>> stackoverflow has a much broader Java community and having traffic go
>> through it could benefit this community.
>
>
> I'm afraid that the main problem is not the tool.
>
> Step 1: an issue is felt as a problem by some people (from the
> community or might-be contributors)
> Step 2: people (from the community) who don't feel the problem
> try to demonstrate that there isn't a problem, thus
> dismissing the (argumented) feeling of others
>
> This can destroy a community, or at least prevent its expansion.
> [And the "Commons" project's (with the word "project" as in "an
> Apache project") community certainly does not benefit from a
> pool of contributors commensurate with its purported goal and
> user base.]
>
> On the practical side, I'm not (yet) against having a single "dev"
> list: discussions about design are usually interesting even if
> applied to another project's codebase (with the the word "project"
> as in "programming project").
>
> But lately, the flood of automatic notifications (commits and CI)
> has drowned the useful discussions.
commits are already sent to a separate list.
I have just recently changed Continuum and the Jenkins Math job to use
commits as well.
What other automatic notifications are still affecting the dev list?
Maybe they can be redirected elsewhere.
> For people who do not contribute to a project (i.e. neither
> providing code nor checking it), a commit diff is just noise
> because they lack context (not being aquainted with the codebase).
Indeed, which is why it is good that they are sent to a different mailing list.
> The Commons community's implied answer to the stated fact is
> that people who feel that way should change their perception of
> reality, or go away.
>
> The respectful answer would be to solve the problem with the
> readily available technology of the 1990s: separate MLs for
> each project's _notifications_ (with the word "project" as in
> "programming project").
As already previously noted, the PMC are responsible for oversight and
so must see all the commits.
Would it really make enough of a difference to non-PMC members to be
worth the additional work (ours and Infra) of setting up individual
commit lists?
>
> Regards,
> Gilles
>
>
>> Ole
>>
>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>
>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>> something like Google Groups where I can set my notification preferences
>>> easily to send me updates only on certain threads such as threads I've
>>> started, which has a nice easily browsable and searchable web interface,
>>> and where I do not have to go through a signup process for each new
>>> group/list I want to post to. I feel many of the problems folks are
>>> talking
>>> about here are caused by using a frustrating technology. E.g. it was
>>> mentioned that if we split mailing lists that joining every list would be
>>> very painful. Perhaps that's because the process of joining just a single
>>> list is too difficult. Having to setup filters is also not very
>>> user-friendly. How do I make a filter that says only put threads on which
>>> I've participated in my inbox? There's probably a way, but it's not as
>>> obvious as clicking a single button. And even with filters I still don't
>>> want most of this garbage coming to my mail account anyway because it
>>> pollutes my search results when I'm looking for something I do care
>>> about.
>>> I signed up for the dev list just so that I could ask that someone
>>> reviews
>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>> (which
>>> I still need help with), but I really have no interest in getting any
>>> commons mail beyond that. I've never participated in any of these other
>>> projects and flooding my inbox is just frustrating and isn't going to
>>> cause
>>> me to start. The web interface for mailing list archives is truly
>>> horrendous.
>>>
>>>
>>>
>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>
>>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>>
>>>>>> ML they see fit?
>>>>>>
>>>>> You missed my point - but never mind.
>>>>>
>>>> What was it?
>>>>
>>>> Judging from your comments below, you completely missed mine.
>>>>
>>>>
>>>>
>>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>>>
>>>>>>> components.
>>>>>>>
>>>>>>
>>>>>> I'm not talking about the size of components, but the size of the
>>>>>> ML traffic.
>>>>>>
>>>>> So just because a component/project has a lot of ML traffic you want
>>>>> to make it TLP?
>>>>>
>>>> I never said that.
>>>> I'm only complaining about ML traffic.
>>>>
>>>> Usually it should be about having enough active committers and users.
>>>>>
>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>> mean the same.
>>>>>
>>>>>
>>>>> I've never a great fan of umbrellas but the components are so small -
>>>>>>>
>>>>>>> I don't see another option. The thought of components to go TLP feels
>>>>>>> just plain silly to me. Hence it would be great to work together as a
>>>>>>> community that takes care of those components.
>>>>>>>
>>>>>>
>>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>>> accept
>>>>>> silly things that result from history (and consider the practical
>>>>>> advantages, as I noted elsewhere).
>>>>>>
>>>>> Well, by the current definition it's not an Apache project. Call it
>>>>> sub-project if you like - I don't care.
>>>>>
>>>> What I'm calling "project" is a _programming_ project; that's the word
>>>> I'm used to; do you have another one?
>>>> Every component is a separate programming project, it's a simple fact.
>>>>
>>>> At some stage we decided to call it component. After all I see it as
>>>>>
>>>>> a library.
>>>>>
>>>>> Do you think it's more and needs to be raised to the level to full
>>>>> blown project like hadoop or httpd?
>>>>> Not sure it Math holds that comparison but you are welcome to convince
>>>>> us.
>>>>>
>>>> I think that this has nothing to do with this thread.
>>>>
>>>>
>>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>>
>>>>>> community" is not very developed...
>>>>>>
>>>>> And that's what I call an oversimplification.
>>>>>
>>>>>
>>>> You brought that up (one community == one list). Or another missed
>>>> point?
>>>>
>>>>
>>>> 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: [ALL] Too much traffic on the "dev" ML
Posted by James Carman <ja...@carmanconsulting.com>.
Well put!!
On Saturday, January 17, 2015, Gilles <gi...@harfang.homelinux.org> wrote:
> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>
>> I agree - we're hung up on a clown from the 90s. It's so much
>> simpler click watch on github and get notifications. Also
>> stackoverflow has a much broader Java community and having traffic go
>> through it could benefit this community.
>>
>
> I'm afraid that the main problem is not the tool.
>
> Step 1: an issue is felt as a problem by some people (from the
> community or might-be contributors)
> Step 2: people (from the community) who don't feel the problem
> try to demonstrate that there isn't a problem, thus
> dismissing the (argumented) feeling of others
>
> This can destroy a community, or at least prevent its expansion.
> [And the "Commons" project's (with the word "project" as in "an
> Apache project") community certainly does not benefit from a
> pool of contributors commensurate with its purported goal and
> user base.]
>
> On the practical side, I'm not (yet) against having a single "dev"
> list: discussions about design are usually interesting even if
> applied to another project's codebase (with the the word "project"
> as in "programming project").
>
> But lately, the flood of automatic notifications (commits and CI)
> has drowned the useful discussions.
> For people who do not contribute to a project (i.e. neither
> providing code nor checking it), a commit diff is just noise
> because they lack context (not being aquainted with the codebase).
>
> The Commons community's implied answer to the stated fact is
> that people who feel that way should change their perception of
> reality, or go away.
>
> The respectful answer would be to solve the problem with the
> readily available technology of the 1990s: separate MLs for
> each project's _notifications_ (with the word "project" as in
> "programming project").
>
>
> Regards,
> Gilles
>
> Ole
>>
>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>
>>> I find the whole I idea of a mailing list very 1990s. I'd much prefer
>>> something like Google Groups where I can set my notification preferences
>>> easily to send me updates only on certain threads such as threads I've
>>> started, which has a nice easily browsable and searchable web interface,
>>> and where I do not have to go through a signup process for each new
>>> group/list I want to post to. I feel many of the problems folks are
>>> talking
>>> about here are caused by using a frustrating technology. E.g. it was
>>> mentioned that if we split mailing lists that joining every list would be
>>> very painful. Perhaps that's because the process of joining just a single
>>> list is too difficult. Having to setup filters is also not very
>>> user-friendly. How do I make a filter that says only put threads on which
>>> I've participated in my inbox? There's probably a way, but it's not as
>>> obvious as clicking a single button. And even with filters I still don't
>>> want most of this garbage coming to my mail account anyway because it
>>> pollutes my search results when I'm looking for something I do care
>>> about.
>>> I signed up for the dev list just so that I could ask that someone
>>> reviews
>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>> (which
>>> I still need help with), but I really have no interest in getting any
>>> commons mail beyond that. I've never participated in any of these other
>>> projects and flooding my inbox is just frustrating and isn't going to
>>> cause
>>> me to start. The web interface for mailing list archives is truly
>>> horrendous.
>>>
>>>
>>>
>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>
>>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>>>
>>>>>> ML they see fit?
>>>>>>
>>>>>> You missed my point - but never mind.
>>>>>
>>>>> What was it?
>>>>
>>>> Judging from your comments below, you completely missed mine.
>>>>
>>>>
>>>>
>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>
>>>>>> components.
>>>>>>>
>>>>>>>
>>>>>> I'm not talking about the size of components, but the size of the
>>>>>> ML traffic.
>>>>>>
>>>>>> So just because a component/project has a lot of ML traffic you want
>>>>> to make it TLP?
>>>>>
>>>>> I never said that.
>>>> I'm only complaining about ML traffic.
>>>>
>>>> Usually it should be about having enough active committers and users.
>>>>
>>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>>> mean the same.
>>>>>
>>>>>
>>>>> I've never a great fan of umbrellas but the components are so small -
>>>>>
>>>>>> I don't see another option. The thought of components to go TLP feels
>>>>>>> just plain silly to me. Hence it would be great to work together as a
>>>>>>> community that takes care of those components.
>>>>>>>
>>>>>>>
>>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>>> accept
>>>>>> silly things that result from history (and consider the practical
>>>>>> advantages, as I noted elsewhere).
>>>>>>
>>>>>> Well, by the current definition it's not an Apache project. Call it
>>>>> sub-project if you like - I don't care.
>>>>>
>>>>> What I'm calling "project" is a _programming_ project; that's the word
>>>> I'm used to; do you have another one?
>>>> Every component is a separate programming project, it's a simple fact.
>>>>
>>>> At some stage we decided to call it component. After all I see it as
>>>>
>>>>> a library.
>>>>>
>>>>> Do you think it's more and needs to be raised to the level to full
>>>>> blown project like hadoop or httpd?
>>>>> Not sure it Math holds that comparison but you are welcome to convince
>>>>> us.
>>>>>
>>>>> I think that this has nothing to do with this thread.
>>>>
>>>>
>>>> If it depends on the name of the list, I guess that the "sense of
>>>>>
>>>>>> community" is not very developed...
>>>>>>
>>>>>> And that's what I call an oversimplification.
>>>>>
>>>>>
>>>>> You brought that up (one community == one list). Or another missed
>>>> point?
>>>>
>>>>
>>>> Gilles
>>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
> I agree - we're hung up on a clown from the 90s. It's so much
> simpler click watch on github and get notifications. Also
> stackoverflow has a much broader Java community and having traffic go
> through it could benefit this community.
I'm afraid that the main problem is not the tool.
Step 1: an issue is felt as a problem by some people (from the
community or might-be contributors)
Step 2: people (from the community) who don't feel the problem
try to demonstrate that there isn't a problem, thus
dismissing the (argumented) feeling of others
This can destroy a community, or at least prevent its expansion.
[And the "Commons" project's (with the word "project" as in "an
Apache project") community certainly does not benefit from a
pool of contributors commensurate with its purported goal and
user base.]
On the practical side, I'm not (yet) against having a single "dev"
list: discussions about design are usually interesting even if
applied to another project's codebase (with the the word "project"
as in "programming project").
But lately, the flood of automatic notifications (commits and CI)
has drowned the useful discussions.
For people who do not contribute to a project (i.e. neither
providing code nor checking it), a commit diff is just noise
because they lack context (not being aquainted with the codebase).
The Commons community's implied answer to the stated fact is
that people who feel that way should change their perception of
reality, or go away.
The respectful answer would be to solve the problem with the
readily available technology of the 1990s: separate MLs for
each project's _notifications_ (with the word "project" as in
"programming project").
Regards,
Gilles
> Ole
>
> On 01/16/2015 10:21 AM, Ben McCann wrote:
>> I find the whole I idea of a mailing list very 1990s. I'd much
>> prefer
>> something like Google Groups where I can set my notification
>> preferences
>> easily to send me updates only on certain threads such as threads
>> I've
>> started, which has a nice easily browsable and searchable web
>> interface,
>> and where I do not have to go through a signup process for each new
>> group/list I want to post to. I feel many of the problems folks are
>> talking
>> about here are caused by using a frustrating technology. E.g. it was
>> mentioned that if we split mailing lists that joining every list
>> would be
>> very painful. Perhaps that's because the process of joining just a
>> single
>> list is too difficult. Having to setup filters is also not very
>> user-friendly. How do I make a filter that says only put threads on
>> which
>> I've participated in my inbox? There's probably a way, but it's not
>> as
>> obvious as clicking a single button. And even with filters I still
>> don't
>> want most of this garbage coming to my mail account anyway because
>> it
>> pollutes my search results when I'm looking for something I do care
>> about.
>> I signed up for the dev list just so that I could ask that someone
>> reviews
>> and commits my patch
>> <https://issues.apache.org/jira/browse/BCEL-186> (which
>> I still need help with), but I really have no interest in getting
>> any
>> commons mail beyond that. I've never participated in any of these
>> other
>> projects and flooding my inbox is just frustrating and isn't going
>> to cause
>> me to start. The web interface for mailing list archives is truly
>> horrendous.
>>
>>
>>
>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>
>>>> Was it mentioned that anybody would be forbidden to subscribe to
>>>> any
>>>>> ML they see fit?
>>>>>
>>>> You missed my point - but never mind.
>>>>
>>> What was it?
>>>
>>> Judging from your comments below, you completely missed mine.
>>>
>>>
>>>
>>>> That comparison is pretty flawed as those projects are not tiny
>>>>>> components.
>>>>>>
>>>>>
>>>>> I'm not talking about the size of components, but the size of the
>>>>> ML traffic.
>>>>>
>>>> So just because a component/project has a lot of ML traffic you
>>>> want
>>>> to make it TLP?
>>>>
>>> I never said that.
>>> I'm only complaining about ML traffic.
>>>
>>> Usually it should be about having enough active committers and
>>> users.
>>>> While this might contribute to ML traffic, it doesn't necessarily
>>>> mean the same.
>>>>
>>>>
>>>> I've never a great fan of umbrellas but the components are so
>>>> small -
>>>>>> I don't see another option. The thought of components to go TLP
>>>>>> feels
>>>>>> just plain silly to me. Hence it would be great to work together
>>>>>> as a
>>>>>> community that takes care of those components.
>>>>>>
>>>>>
>>>>> The idea of "Commons Math" being a component is silly, but we can
>>>>> accept
>>>>> silly things that result from history (and consider the practical
>>>>> advantages, as I noted elsewhere).
>>>>>
>>>> Well, by the current definition it's not an Apache project. Call
>>>> it
>>>> sub-project if you like - I don't care.
>>>>
>>> What I'm calling "project" is a _programming_ project; that's the
>>> word
>>> I'm used to; do you have another one?
>>> Every component is a separate programming project, it's a simple
>>> fact.
>>>
>>> At some stage we decided to call it component. After all I see it
>>> as
>>>> a library.
>>>>
>>>> Do you think it's more and needs to be raised to the level to full
>>>> blown project like hadoop or httpd?
>>>> Not sure it Math holds that comparison but you are welcome to
>>>> convince us.
>>>>
>>> I think that this has nothing to do with this thread.
>>>
>>>
>>>> If it depends on the name of the list, I guess that the "sense
>>>> of
>>>>> community" is not very developed...
>>>>>
>>>> And that's what I call an oversimplification.
>>>>
>>>>
>>> You brought that up (one community == one list). Or another missed
>>> point?
>>>
>>>
>>> Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Ole Ersoy <ol...@gmail.com>.
I agree - we're hung up on a clown from the 90s. It's so much simpler click watch on github and get notifications. Also stackoverflow has a much broader Java community and having traffic go through it could benefit this community.
Ole
On 01/16/2015 10:21 AM, Ben McCann wrote:
> I find the whole I idea of a mailing list very 1990s. I'd much prefer
> something like Google Groups where I can set my notification preferences
> easily to send me updates only on certain threads such as threads I've
> started, which has a nice easily browsable and searchable web interface,
> and where I do not have to go through a signup process for each new
> group/list I want to post to. I feel many of the problems folks are talking
> about here are caused by using a frustrating technology. E.g. it was
> mentioned that if we split mailing lists that joining every list would be
> very painful. Perhaps that's because the process of joining just a single
> list is too difficult. Having to setup filters is also not very
> user-friendly. How do I make a filter that says only put threads on which
> I've participated in my inbox? There's probably a way, but it's not as
> obvious as clicking a single button. And even with filters I still don't
> want most of this garbage coming to my mail account anyway because it
> pollutes my search results when I'm looking for something I do care about.
> I signed up for the dev list just so that I could ask that someone reviews
> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186> (which
> I still need help with), but I really have no interest in getting any
> commons mail beyond that. I've never participated in any of these other
> projects and flooding my inbox is just frustrating and isn't going to cause
> me to start. The web interface for mailing list archives is truly
> horrendous.
>
>
>
> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
>> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>
>>> Was it mentioned that anybody would be forbidden to subscribe to any
>>>> ML they see fit?
>>>>
>>> You missed my point - but never mind.
>>>
>> What was it?
>>
>> Judging from your comments below, you completely missed mine.
>>
>>
>>
>>> That comparison is pretty flawed as those projects are not tiny
>>>>> components.
>>>>>
>>>>
>>>> I'm not talking about the size of components, but the size of the
>>>> ML traffic.
>>>>
>>> So just because a component/project has a lot of ML traffic you want
>>> to make it TLP?
>>>
>> I never said that.
>> I'm only complaining about ML traffic.
>>
>> Usually it should be about having enough active committers and users.
>>> While this might contribute to ML traffic, it doesn't necessarily
>>> mean the same.
>>>
>>>
>>> I've never a great fan of umbrellas but the components are so small -
>>>>> I don't see another option. The thought of components to go TLP feels
>>>>> just plain silly to me. Hence it would be great to work together as a
>>>>> community that takes care of those components.
>>>>>
>>>>
>>>> The idea of "Commons Math" being a component is silly, but we can accept
>>>> silly things that result from history (and consider the practical
>>>> advantages, as I noted elsewhere).
>>>>
>>> Well, by the current definition it's not an Apache project. Call it
>>> sub-project if you like - I don't care.
>>>
>> What I'm calling "project" is a _programming_ project; that's the word
>> I'm used to; do you have another one?
>> Every component is a separate programming project, it's a simple fact.
>>
>> At some stage we decided to call it component. After all I see it as
>>> a library.
>>>
>>> Do you think it's more and needs to be raised to the level to full
>>> blown project like hadoop or httpd?
>>> Not sure it Math holds that comparison but you are welcome to convince us.
>>>
>> I think that this has nothing to do with this thread.
>>
>>
>>> If it depends on the name of the list, I guess that the "sense of
>>>> community" is not very developed...
>>>>
>>> And that's what I call an oversimplification.
>>>
>>>
>> You brought that up (one community == one list). Or another missed point?
>>
>>
>> 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: [ALL] Too much traffic on the "dev" ML
Posted by Ben McCann <be...@benmccann.com>.
I find the whole I idea of a mailing list very 1990s. I'd much prefer
something like Google Groups where I can set my notification preferences
easily to send me updates only on certain threads such as threads I've
started, which has a nice easily browsable and searchable web interface,
and where I do not have to go through a signup process for each new
group/list I want to post to. I feel many of the problems folks are talking
about here are caused by using a frustrating technology. E.g. it was
mentioned that if we split mailing lists that joining every list would be
very painful. Perhaps that's because the process of joining just a single
list is too difficult. Having to setup filters is also not very
user-friendly. How do I make a filter that says only put threads on which
I've participated in my inbox? There's probably a way, but it's not as
obvious as clicking a single button. And even with filters I still don't
want most of this garbage coming to my mail account anyway because it
pollutes my search results when I'm looking for something I do care about.
I signed up for the dev list just so that I could ask that someone reviews
and commits my patch <https://issues.apache.org/jira/browse/BCEL-186> (which
I still need help with), but I really have no interest in getting any
commons mail beyond that. I've never participated in any of these other
projects and flooding my inbox is just frustrating and isn't going to cause
me to start. The web interface for mailing list archives is truly
horrendous.
On Fri, Jan 16, 2015 at 8:16 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>
>> Was it mentioned that anybody would be forbidden to subscribe to any
>>> ML they see fit?
>>>
>>
>> You missed my point - but never mind.
>>
>
> What was it?
>
> Judging from your comments below, you completely missed mine.
>
>
>
>> That comparison is pretty flawed as those projects are not tiny
>>>> components.
>>>>
>>>
>>>
>>> I'm not talking about the size of components, but the size of the
>>> ML traffic.
>>>
>>
>> So just because a component/project has a lot of ML traffic you want
>> to make it TLP?
>>
>
> I never said that.
> I'm only complaining about ML traffic.
>
> Usually it should be about having enough active committers and users.
>> While this might contribute to ML traffic, it doesn't necessarily
>> mean the same.
>>
>>
>> I've never a great fan of umbrellas but the components are so small -
>>>> I don't see another option. The thought of components to go TLP feels
>>>> just plain silly to me. Hence it would be great to work together as a
>>>> community that takes care of those components.
>>>>
>>>
>>>
>>> The idea of "Commons Math" being a component is silly, but we can accept
>>> silly things that result from history (and consider the practical
>>> advantages, as I noted elsewhere).
>>>
>>
>> Well, by the current definition it's not an Apache project. Call it
>> sub-project if you like - I don't care.
>>
>
> What I'm calling "project" is a _programming_ project; that's the word
> I'm used to; do you have another one?
> Every component is a separate programming project, it's a simple fact.
>
> At some stage we decided to call it component. After all I see it as
>> a library.
>>
>> Do you think it's more and needs to be raised to the level to full
>> blown project like hadoop or httpd?
>> Not sure it Math holds that comparison but you are welcome to convince us.
>>
>
> I think that this has nothing to do with this thread.
>
>
>> If it depends on the name of the list, I guess that the "sense of
>>> community" is not very developed...
>>>
>>
>> And that's what I call an oversimplification.
>>
>>
> You brought that up (one community == one list). Or another missed point?
>
>
> Gilles
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
about.me/benmccann
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>> Was it mentioned that anybody would be forbidden to subscribe to any
>> ML they see fit?
>
> You missed my point - but never mind.
What was it?
Judging from your comments below, you completely missed mine.
>
>>> That comparison is pretty flawed as those projects are not tiny
>>> components.
>>
>>
>> I'm not talking about the size of components, but the size of the
>> ML traffic.
>
> So just because a component/project has a lot of ML traffic you want
> to make it TLP?
I never said that.
I'm only complaining about ML traffic.
> Usually it should be about having enough active committers and users.
> While this might contribute to ML traffic, it doesn't necessarily
> mean the same.
>
>
>>> I've never a great fan of umbrellas but the components are so small
>>> -
>>> I don't see another option. The thought of components to go TLP
>>> feels
>>> just plain silly to me. Hence it would be great to work together as
>>> a
>>> community that takes care of those components.
>>
>>
>> The idea of "Commons Math" being a component is silly, but we can
>> accept
>> silly things that result from history (and consider the practical
>> advantages, as I noted elsewhere).
>
> Well, by the current definition it's not an Apache project. Call it
> sub-project if you like - I don't care.
What I'm calling "project" is a _programming_ project; that's the word
I'm used to; do you have another one?
Every component is a separate programming project, it's a simple fact.
> At some stage we decided to call it component. After all I see it as
> a library.
>
> Do you think it's more and needs to be raised to the level to full
> blown project like hadoop or httpd?
> Not sure it Math holds that comparison but you are welcome to
> convince us.
I think that this has nothing to do with this thread.
>
>> If it depends on the name of the list, I guess that the "sense of
>> community" is not very developed...
>
> And that's what I call an oversimplification.
>
You brought that up (one community == one list). Or another missed
point?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Torsten Curdt <tc...@vafer.org>.
> Was it mentioned that anybody would be forbidden to subscribe to any
> ML they see fit?
You missed my point - but never mind.
>> That comparison is pretty flawed as those projects are not tiny
>> components.
>
>
> I'm not talking about the size of components, but the size of the
> ML traffic.
So just because a component/project has a lot of ML traffic you want
to make it TLP?
Usually it should be about having enough active committers and users.
While this might contribute to ML traffic, it doesn't necessarily mean the same.
>> I've never a great fan of umbrellas but the components are so small -
>> I don't see another option. The thought of components to go TLP feels
>> just plain silly to me. Hence it would be great to work together as a
>> community that takes care of those components.
>
>
> The idea of "Commons Math" being a component is silly, but we can accept
> silly things that result from history (and consider the practical
> advantages, as I noted elsewhere).
Well, by the current definition it's not an Apache project. Call it
sub-project if you like - I don't care.
At some stage we decided to call it component. After all I see it as a library.
Do you think it's more and needs to be raised to the level to full
blown project like hadoop or httpd?
Not sure it Math holds that comparison but you are welcome to convince us.
> If it depends on the name of the list, I guess that the "sense of
> community" is not very developed...
And that's what I call an oversimplification.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 15:54:40 +0100, Torsten Curdt wrote:
>> Concerning [Math], when the possibility was raised, the majority
>> thought that development within Commons had practical advantages
>> (through shared burden of the development environment).
>>
>> I'm stating again the fact that nobody is involved in a "Commons"
>> project programming-wise; hence it does not make sense, in
>> principle,
>> to have to share the programming discussions on the same ML.
>
> The conclusion you derive from the fact is only an opinion though.
> Maybe it does make sense for others to hear what's going on in Math?
> ...and be it just for the board reports?
Was it mentioned that anybody would be forbidden to subscribe to any
ML they see fit?
The name of the list is what defines the broad subject of discussion:
discussing the develoment of Commons Math is done on
math-dev@commons...
I'm afraid that people find this so strange... :-{
>> If it did, all the Apache (programming) project could as well share
>> the same list. [We'd just have to set up filters, wouldn't we?]
>
> That comparison is pretty flawed as those projects are not tiny
> components.
I'm not talking about the size of components, but the size of the
ML traffic.
> I've never a great fan of umbrellas but the components are so small -
> I don't see another option. The thought of components to go TLP feels
> just plain silly to me. Hence it would be great to work together as a
> community that takes care of those components.
The idea of "Commons Math" being a component is silly, but we can
accept
silly things that result from history (and consider the practical
advantages, as I noted elsewhere).
> While from a practical standpoint (if everyone filters anyway) you
> might be right, my guess is that a community with many list will not
> have the same feeling of affiliation.
If it depends on the name of the list, I guess that the "sense of
community" is not very developed...
Gilles
>
> cheers,
> Torsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Torsten Curdt <tc...@vafer.org>.
> Concerning [Math], when the possibility was raised, the majority
> thought that development within Commons had practical advantages
> (through shared burden of the development environment).
>
> I'm stating again the fact that nobody is involved in a "Commons"
> project programming-wise; hence it does not make sense, in principle,
> to have to share the programming discussions on the same ML.
The conclusion you derive from the fact is only an opinion though.
Maybe it does make sense for others to hear what's going on in Math?
...and be it just for the board reports?
> If it did, all the Apache (programming) project could as well share
> the same list. [We'd just have to set up filters, wouldn't we?]
That comparison is pretty flawed as those projects are not tiny components.
I've never a great fan of umbrellas but the components are so small -
I don't see another option. The thought of components to go TLP feels
just plain silly to me. Hence it would be great to work together as a
community that takes care of those components.
While from a practical standpoint (if everyone filters anyway) you
might be right, my guess is that a community with many list will not
have the same feeling of affiliation.
cheers,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 12:36:27 +0000, Mark Thomas wrote:
> On 16/01/2015 11:18, Gilles wrote:
>> On Fri, 16 Jan 2015 10:40:18 +0000, Mark Thomas wrote:
>>> On 16/01/2015 07:53, Benedikt Ritter wrote:
>>>> Hi Gilles,
>>>>
>>>> 2015-01-16 1:47 GMT+01:00 Gilles <gi...@harfang.homelinux.org>:
>>>>
>>>>> Hi.
>>>>>
>>>>> In the discussion that started about RDF, it seems that the
>>>>> traffic volume is a stumbling block.
>>>>> [For some time now, it has been a growing nuisance, and the
>>>>> usual dismissal about filters won't change the fact: Setting
>>>>> up a filter that will redirect stuff to /dev/null is a waste
>>>>> of bandwidth.]
>>>>>
>>>>> If different ML are created, people interested in everything
>>>>> can subscribe _once_, and nothing will change for them.
>>>>> For people who spend a lot of time just deleting dozens messages
>>>>> and notifications a day, it will be a relief.
>>>>>
>>>>> Maintaining community conversation is not a problem: just
>>>>> create an "all-dev@commons.apache.org" ML for things that
>>>>> need input form a larger audience (like votes).
>>>>>
>>>>
>>>> Personally I don't care. I have filters set up and if we would do
>>>> the
>>>> much,
>>>> I'd simply subscribe to all MLs.
>>>> I agree that it seems to be a problem for some that the ML has so
>>>> much
>>>> traffic. So we should think about this.
>>>>
>>>> There are two questions for me:
>>>>
>>>> - What about commits@ and issues@? Do we simply route commits and
>>>> issues to
>>>> the component MLs or do we want to have separate commit MLs on a
>>>> per
>>>> component basis?
>>>> - How do we want to manage the transition? I think the process we
>>>> choose
>>>> for the git migration is a good one. If a component decides it
>>>> needs a
>>>> separate ML, they can simply request one. All other components
>>>> simply
>>>> stay
>>>> on dev@ For example I don't see much value in creating a
>>>> primities@comons.apache.org ML, simply because there is so low
>>>> activity
>>>> right now.
>>>
>>> Components with enough activity to sustain separate lists should be
>>> moving to a TLP.
>>
>> So this is again an issue with an "all or nothing" solution?
>
> The point is that long experience at the ASF tells us that umbrellas
> are
> bad. There were good reasons that Jakarta was broken up.
>
> Commons isn't a new Jakarta yet but discussions that stem from part A
> of
> the Commons community wanting to isolate themselves from the rest of
> the
> Commons community
That's a wrong interpretation. I want to suppress at the source what
others seem to suppress using mail client filters.
> are a good indication that part A of the Commons
> community should be looking to move to TLP status.
Concerning [Math], when the possibility was raised, the majority
thought that development within Commons had practical advantages
(through shared burden of the development environment).
I'm stating again the fact that nobody is involved in a "Commons"
project programming-wise; hence it does not make sense, in principle,
to have to share the programming discussions on the same ML.
If it did, all the Apache (programming) project could as well share
the same list. [We'd just have to set up filters, wouldn't we?]
Gilles
>
> Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Mark Thomas <ma...@apache.org>.
On 16/01/2015 11:18, Gilles wrote:
> On Fri, 16 Jan 2015 10:40:18 +0000, Mark Thomas wrote:
>> On 16/01/2015 07:53, Benedikt Ritter wrote:
>>> Hi Gilles,
>>>
>>> 2015-01-16 1:47 GMT+01:00 Gilles <gi...@harfang.homelinux.org>:
>>>
>>>> Hi.
>>>>
>>>> In the discussion that started about RDF, it seems that the
>>>> traffic volume is a stumbling block.
>>>> [For some time now, it has been a growing nuisance, and the
>>>> usual dismissal about filters won't change the fact: Setting
>>>> up a filter that will redirect stuff to /dev/null is a waste
>>>> of bandwidth.]
>>>>
>>>> If different ML are created, people interested in everything
>>>> can subscribe _once_, and nothing will change for them.
>>>> For people who spend a lot of time just deleting dozens messages
>>>> and notifications a day, it will be a relief.
>>>>
>>>> Maintaining community conversation is not a problem: just
>>>> create an "all-dev@commons.apache.org" ML for things that
>>>> need input form a larger audience (like votes).
>>>>
>>>
>>> Personally I don't care. I have filters set up and if we would do the
>>> much,
>>> I'd simply subscribe to all MLs.
>>> I agree that it seems to be a problem for some that the ML has so much
>>> traffic. So we should think about this.
>>>
>>> There are two questions for me:
>>>
>>> - What about commits@ and issues@? Do we simply route commits and
>>> issues to
>>> the component MLs or do we want to have separate commit MLs on a per
>>> component basis?
>>> - How do we want to manage the transition? I think the process we choose
>>> for the git migration is a good one. If a component decides it needs a
>>> separate ML, they can simply request one. All other components simply
>>> stay
>>> on dev@ For example I don't see much value in creating a
>>> primities@comons.apache.org ML, simply because there is so low activity
>>> right now.
>>
>> Components with enough activity to sustain separate lists should be
>> moving to a TLP.
>
> So this is again an issue with an "all or nothing" solution?
The point is that long experience at the ASF tells us that umbrellas are
bad. There were good reasons that Jakarta was broken up.
Commons isn't a new Jakarta yet but discussions that stem from part A of
the Commons community wanting to isolate themselves from the rest of the
Commons community are a good indication that part A of the Commons
community should be looking to move to TLP status.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 10:40:18 +0000, Mark Thomas wrote:
> On 16/01/2015 07:53, Benedikt Ritter wrote:
>> Hi Gilles,
>>
>> 2015-01-16 1:47 GMT+01:00 Gilles <gi...@harfang.homelinux.org>:
>>
>>> Hi.
>>>
>>> In the discussion that started about RDF, it seems that the
>>> traffic volume is a stumbling block.
>>> [For some time now, it has been a growing nuisance, and the
>>> usual dismissal about filters won't change the fact: Setting
>>> up a filter that will redirect stuff to /dev/null is a waste
>>> of bandwidth.]
>>>
>>> If different ML are created, people interested in everything
>>> can subscribe _once_, and nothing will change for them.
>>> For people who spend a lot of time just deleting dozens messages
>>> and notifications a day, it will be a relief.
>>>
>>> Maintaining community conversation is not a problem: just
>>> create an "all-dev@commons.apache.org" ML for things that
>>> need input form a larger audience (like votes).
>>>
>>
>> Personally I don't care. I have filters set up and if we would do
>> the much,
>> I'd simply subscribe to all MLs.
>> I agree that it seems to be a problem for some that the ML has so
>> much
>> traffic. So we should think about this.
>>
>> There are two questions for me:
>>
>> - What about commits@ and issues@? Do we simply route commits and
>> issues to
>> the component MLs or do we want to have separate commit MLs on a per
>> component basis?
>> - How do we want to manage the transition? I think the process we
>> choose
>> for the git migration is a good one. If a component decides it needs
>> a
>> separate ML, they can simply request one. All other components
>> simply stay
>> on dev@ For example I don't see much value in creating a
>> primities@comons.apache.org ML, simply because there is so low
>> activity
>> right now.
>
> Components with enough activity to sustain separate lists should be
> moving to a TLP.
So this is again an issue with an "all or nothing" solution?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Mark Thomas <ma...@apache.org>.
On 16/01/2015 07:53, Benedikt Ritter wrote:
> Hi Gilles,
>
> 2015-01-16 1:47 GMT+01:00 Gilles <gi...@harfang.homelinux.org>:
>
>> Hi.
>>
>> In the discussion that started about RDF, it seems that the
>> traffic volume is a stumbling block.
>> [For some time now, it has been a growing nuisance, and the
>> usual dismissal about filters won't change the fact: Setting
>> up a filter that will redirect stuff to /dev/null is a waste
>> of bandwidth.]
>>
>> If different ML are created, people interested in everything
>> can subscribe _once_, and nothing will change for them.
>> For people who spend a lot of time just deleting dozens messages
>> and notifications a day, it will be a relief.
>>
>> Maintaining community conversation is not a problem: just
>> create an "all-dev@commons.apache.org" ML for things that
>> need input form a larger audience (like votes).
>>
>
> Personally I don't care. I have filters set up and if we would do the much,
> I'd simply subscribe to all MLs.
> I agree that it seems to be a problem for some that the ML has so much
> traffic. So we should think about this.
>
> There are two questions for me:
>
> - What about commits@ and issues@? Do we simply route commits and issues to
> the component MLs or do we want to have separate commit MLs on a per
> component basis?
> - How do we want to manage the transition? I think the process we choose
> for the git migration is a good one. If a component decides it needs a
> separate ML, they can simply request one. All other components simply stay
> on dev@ For example I don't see much value in creating a
> primities@comons.apache.org ML, simply because there is so low activity
> right now.
Components with enough activity to sustain separate lists should be
moving to a TLP.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by sebb <se...@gmail.com>.
On 16 January 2015 at 11:13, Gilles <gi...@harfang.homelinux.org> wrote:
> On Fri, 16 Jan 2015 08:53:56 +0100, Benedikt Ritter wrote:
>>
>> Hi Gilles,
>>
>> 2015-01-16 1:47 GMT+01:00 Gilles <gi...@harfang.homelinux.org>:
>>
>>> Hi.
>>>
>>> In the discussion that started about RDF, it seems that the
>>> traffic volume is a stumbling block.
>>> [For some time now, it has been a growing nuisance, and the
>>> usual dismissal about filters won't change the fact: Setting
>>> up a filter that will redirect stuff to /dev/null is a waste
>>> of bandwidth.]
>>>
>>> If different ML are created, people interested in everything
>>> can subscribe _once_, and nothing will change for them.
>>> For people who spend a lot of time just deleting dozens messages
>>> and notifications a day, it will be a relief.
>>>
>>> Maintaining community conversation is not a problem: just
>>> create an "all-dev@commons.apache.org" ML for things that
>>> need input form a larger audience (like votes).
>>>
>>
>> Personally I don't care. I have filters set up and if we would do the
>> much,
>> I'd simply subscribe to all MLs.
>> I agree that it seems to be a problem for some that the ML has so much
>> traffic. So we should think about this.
>>
>> There are two questions for me:
>>
>> - What about commits@ and issues@? Do we simply route commits and issues
>> to
>> the component MLs or do we want to have separate commit MLs on a per
>> component basis?
>
>
> A developer who is active on some component would presumably want to
> see commit activity.
> Conversely, commit reports on code that one does not touch or read are
> not interesting by default.
However PMC members would have to subscribe to every single list, as
the PMC must have oversight of them.
I don't think that is viable if there are separate lists for each component.
If we are trying to make it easier for new-comers, then yes, trimming
down the dev list might help.
But the way to do that is to ensure that automated mails such as CI
builds are moved to one of the other lists.
>> - How do we want to manage the transition? I think the process we choose
>> for the git migration is a good one. If a component decides it needs a
>> separate ML, they can simply request one. All other components simply stay
>> on dev@ For example I don't see much value in creating a
>> primities@comons.apache.org ML, simply because there is so low activity
>> right now.
>
>
> Suppose that someone is interested in some component that is not on
> a separate ML, he will still get all the traffic...
> People who want the traffic can subscribe to everything. [It would even
> be OK to be automatically subscribed to every new list, and people would
> need to explicitly unsubscribe...]
>
>
> Regards,
> Gilles
>
>
>>
>> Regards,
>> Benedikt
>
>
>
> ---------------------------------------------------------------------
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 16 Jan 2015 08:53:56 +0100, Benedikt Ritter wrote:
> Hi Gilles,
>
> 2015-01-16 1:47 GMT+01:00 Gilles <gi...@harfang.homelinux.org>:
>
>> Hi.
>>
>> In the discussion that started about RDF, it seems that the
>> traffic volume is a stumbling block.
>> [For some time now, it has been a growing nuisance, and the
>> usual dismissal about filters won't change the fact: Setting
>> up a filter that will redirect stuff to /dev/null is a waste
>> of bandwidth.]
>>
>> If different ML are created, people interested in everything
>> can subscribe _once_, and nothing will change for them.
>> For people who spend a lot of time just deleting dozens messages
>> and notifications a day, it will be a relief.
>>
>> Maintaining community conversation is not a problem: just
>> create an "all-dev@commons.apache.org" ML for things that
>> need input form a larger audience (like votes).
>>
>
> Personally I don't care. I have filters set up and if we would do the
> much,
> I'd simply subscribe to all MLs.
> I agree that it seems to be a problem for some that the ML has so
> much
> traffic. So we should think about this.
>
> There are two questions for me:
>
> - What about commits@ and issues@? Do we simply route commits and
> issues to
> the component MLs or do we want to have separate commit MLs on a per
> component basis?
A developer who is active on some component would presumably want to
see commit activity.
Conversely, commit reports on code that one does not touch or read are
not interesting by default.
> - How do we want to manage the transition? I think the process we
> choose
> for the git migration is a good one. If a component decides it needs
> a
> separate ML, they can simply request one. All other components simply
> stay
> on dev@ For example I don't see much value in creating a
> primities@comons.apache.org ML, simply because there is so low
> activity
> right now.
Suppose that someone is interested in some component that is not on
a separate ML, he will still get all the traffic...
People who want the traffic can subscribe to everything. [It would even
be OK to be automatically subscribed to every new list, and people
would
need to explicitly unsubscribe...]
Regards,
Gilles
>
> Regards,
> Benedikt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Too much traffic on the "dev" ML
Posted by Benedikt Ritter <br...@apache.org>.
Hi Gilles,
2015-01-16 1:47 GMT+01:00 Gilles <gi...@harfang.homelinux.org>:
> Hi.
>
> In the discussion that started about RDF, it seems that the
> traffic volume is a stumbling block.
> [For some time now, it has been a growing nuisance, and the
> usual dismissal about filters won't change the fact: Setting
> up a filter that will redirect stuff to /dev/null is a waste
> of bandwidth.]
>
> If different ML are created, people interested in everything
> can subscribe _once_, and nothing will change for them.
> For people who spend a lot of time just deleting dozens messages
> and notifications a day, it will be a relief.
>
> Maintaining community conversation is not a problem: just
> create an "all-dev@commons.apache.org" ML for things that
> need input form a larger audience (like votes).
>
Personally I don't care. I have filters set up and if we would do the much,
I'd simply subscribe to all MLs.
I agree that it seems to be a problem for some that the ML has so much
traffic. So we should think about this.
There are two questions for me:
- What about commits@ and issues@? Do we simply route commits and issues to
the component MLs or do we want to have separate commit MLs on a per
component basis?
- How do we want to manage the transition? I think the process we choose
for the git migration is a good one. If a component decides it needs a
separate ML, they can simply request one. All other components simply stay
on dev@ For example I don't see much value in creating a
primities@comons.apache.org ML, simply because there is so low activity
right now.
Regards,
Benedikt
>
>
> Best regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> 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: [ALL] Too much traffic on the "dev" ML
Posted by Stian Soiland-Reyes <st...@apache.org>.
While I am part of the [RDF] community - I would be careful about
sub-lists with "too few people" (e.g. <3).
As you said, voting on releases (and other PMC-level votes) should be
kept on the all-dev - formally then the sublist should not be a worry
- you wouldn't make a mailing list for two people anyway. Commits and
issues should definitely be on the sub-lists, if they exists - as they
would be part of the overall noise for everyone else.
It would be a relief to the [RDF] community, a separate mailing list
(e.g. rdf@commons.apache.org) would make it much more accessible to
invite non-committer third-parties who are involved just with
Commons-RDF during its design phase.
There's a danger of small & fresh sandbox communities ending up in a
fragmenting "mini incubator" (without the usual checks and balances)
if they start straight off in separate mailing lists. I would assume
only established sub-communities would go straight to a sub-mailing
list.
Some older/stable commons-* things might not benefit have a dead
mailing list with 3 people - it's better emails from a user of
commons-semiabandoned get picked up in general list (hoping for a
volunteer) - so I guess this would be up for each sub-community to do
a [$project][VOTE] to see if they want their own sub-list. +3 should
be sufficient.
Perhaps forwarding this thread to the general@incubator list would be
appropriate - there we are currently discussing the possibility of
fresh projects bypassing the incubator process and become a
"probationary" TLP reporting directly to the board, and rather require
3 active mentors (with experience from "proper" PMCs) on the new PMC:
https://wiki.apache.org/incubator/IncubatorV2 (whenever the wiki is online)
http://mail-archives.apache.org/mod_mbox/incubator-general/201501.mbox/%3CCALhtWkcPptYsE%2BrpF42z75zNU%3DHKbcom7XC%3DU4LqmD_grWQg3Q%40mail.gmail.com%3E
Incoming Apache-majority communities like [RDF] and established,
active commons-* modules would probably fulfil that requirement
directly. The proposals have not mentioned what is the plan for
non-TLP podlings.
On 16 January 2015 at 00:47, Gilles <gi...@harfang.homelinux.org> wrote:
> Hi.
>
> In the discussion that started about RDF, it seems that the
> traffic volume is a stumbling block.
> [For some time now, it has been a growing nuisance, and the
> usual dismissal about filters won't change the fact: Setting
> up a filter that will redirect stuff to /dev/null is a waste
> of bandwidth.]
>
> If different ML are created, people interested in everything
> can subscribe _once_, and nothing will change for them.
> For people who spend a lot of time just deleting dozens messages
> and notifications a day, it will be a relief.
>
> Maintaining community conversation is not a problem: just
> create an "all-dev@commons.apache.org" ML for things that
> need input form a larger audience (like votes).
>
>
> Best regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> 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