On Fri, 16 Jan 2015 08:53:56 +0100, 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?
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
primit...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
