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 <gil...@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-...@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
primit...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
