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