Am 16.01.2015 um 16:19 schrieb Duncan Jones:
> On 16 January 2015 at 14:54, Torsten Curdt <tcu...@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-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to