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