[ALL] Too much traffic on the "dev" ML

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[ALL] Too much traffic on the "dev" ML

Gilles Sadowski
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 "[hidden email]" ML for things that
need input form a larger audience (like votes).


Best regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Benedikt Ritter-4
Hi Gilles,

2015-01-16 1:47 GMT+01:00 Gilles <[hidden email]>:

> 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 "[hidden email]" 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
[hidden email] ML, simply because there is so low activity
right now.

Regards,
Benedikt


>
>
> Best regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Mark Thomas
On 16/01/2015 07:53, Benedikt Ritter wrote:

> Hi Gilles,
>
> 2015-01-16 1:47 GMT+01:00 Gilles <[hidden email]>:
>
>> 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 "[hidden email]" 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
> [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

sebb-2-2
On 16 January 2015 at 10:49, Emmanuel Bourg <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Gilles Sadowski
In reply to this post by Benedikt Ritter-4
On Fri, 16 Jan 2015 08:53:56 +0100, Benedikt Ritter wrote:

> Hi Gilles,
>
> 2015-01-16 1:47 GMT+01:00 Gilles <[hidden email]>:
>
>> 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 "[hidden email]" 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
> [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Emmanuel Bourg-3
In reply to this post by sebb-2-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Gilles Sadowski
In reply to this post by Mark Thomas
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 <[hidden email]>:
>>
>>> 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 "[hidden email]" 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
>> [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

sebb-2-2
In reply to this post by Emmanuel Bourg-3
On 16 January 2015 at 11:16, Emmanuel Bourg <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

sebb-2-2
In reply to this post by Gilles Sadowski
On 16 January 2015 at 11:13, Gilles <[hidden email]> wrote:

> On Fri, 16 Jan 2015 08:53:56 +0100, Benedikt Ritter wrote:
>>
>> Hi Gilles,
>>
>> 2015-01-16 1:47 GMT+01:00 Gilles <[hidden email]>:
>>
>>> 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 "[hidden email]" 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
>> [hidden email] 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

sebb-2-2
In reply to this post by sebb-2-2
On 16 January 2015 at 11:21, sebb <[hidden email]> wrote:

> On 16 January 2015 at 11:16, Emmanuel Bourg <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Bruno P. Kinoshita
In reply to this post by Gilles Sadowski
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 <[hidden email]>
>To: Commons Developers List <[hidden email]>
>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 "[hidden email]" ML for things that
>need input form a larger audience (like votes).
>
>
>Best regards,
>Gilles
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Kristian Rosenvold
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Jörg Schaible-4
In reply to this post by Emmanuel Bourg-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Mark Thomas
In reply to this post by Gilles Sadowski
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 <[hidden email]>:
>>>
>>>> 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 "[hidden email]" 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
>>> [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Gilles Sadowski
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 <[hidden email]>:
>>>>
>>>>> 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 "[hidden email]" 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
>>>> [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Torsten Curdt-3
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Too much traffic on the "dev" ML

Duncan Jones
In reply to this post by Torsten Curdt-3
On 16 January 2015 at 14:54, Torsten Curdt <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123