Re: [PROPOSAL] One development list
Care to elaborate a bit? I'd argue that for the people who care it's no big deal to subscribe to the various lists. So tuning in is no problem, tuning out once consolidated indeed is. It's an all-or-nothing. How is oversight better when everyone (or at least all PMC members) are subscribed to all dev list as opposed to just the one? While the one dev list might work OK for Commons I have the feeling that these projects are just too different. In Commons one could imagine to step up for another component. I don't see that with the rest that is left at jakarta. If there are many cross-posting (that would be a sign for cross-concerns) I haven't noticed any. At least I don't see the benefits of a consolidation. I would rather ask all PMC members to subscribe to all dev list than merging the lists. Not to talk about the mailing list archive confusions and hassle this might create. but well - that's just my opinion and the -1 should not be blocking. Just saying that I don't like the idea. cheers -- Torsten - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [PROPOSAL] One development list
On Sat, Oct 10, 2009 at 2:04 PM, Torsten Curdt tcu...@vafer.org wrote: Care to elaborate a bit? I'd argue that for the people who care it's no big deal to subscribe to the various lists. So tuning in is no problem, tuning out once consolidated indeed is. It's an all-or-nothing. How is oversight better when everyone (or at least all PMC members) are subscribed to all dev list as opposed to just the one? snip/ Its not. But expecting all PMC members to be on one dev list constitutes a much gentler forcing function. While the one dev list might work OK for Commons I have the feeling that these projects are just too different. In Commons one could imagine to step up for another component. I don't see that with the rest that is left at jakarta. If there are many cross-posting (that would be a sign for cross-concerns) I haven't noticed any. At least I don't see the benefits of a consolidation. I would rather ask all PMC members to subscribe to all dev list than merging the lists. Not to talk about the mailing list archive confusions and hassle this might create. snap/ My claim is that sharing a mailing list is a solved problem. sebb pushing out BSF 3.0 is an example of someone stepping up for another component -- more exception than rule, yes. but well - that's just my opinion and the -1 should not be blocking. Just saying that I don't like the idea. snip/ Sure, and I'm not trying to get you to like it, rather to understand your initial response a little better. Thanks for elaborating. -Rahul cheers -- Torsten - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: [PROPOSAL] One development list
On 11/10/2009, Rahul Akolkar rahul.akol...@gmail.com wrote: On Sat, Oct 10, 2009 at 2:04 PM, Torsten Curdt tcu...@vafer.org wrote: Care to elaborate a bit? I'd argue that for the people who care it's no big deal to subscribe to the various lists. So tuning in is no problem, tuning out once consolidated indeed is. It's an all-or-nothing. How is oversight better when everyone (or at least all PMC members) are subscribed to all dev list as opposed to just the one? snip/ Its not. But expecting all PMC members to be on one dev list constitutes a much gentler forcing function. While the one dev list might work OK for Commons I have the feeling that these projects are just too different. In Commons one could imagine to step up for another component. I don't see that with the rest that is left at jakarta. If there are many cross-posting (that would be a sign for cross-concerns) I haven't noticed any. At least I don't see the benefits of a consolidation. I would rather ask all PMC members to subscribe to all dev list than merging the lists. Not to talk about the mailing list archive confusions and hassle this might create. snap/ My claim is that sharing a mailing list is a solved problem. sebb pushing out BSF 3.0 is an example of someone stepping up for another component -- more exception than rule, yes. BTW, I was already subscribed to BSF-dev because JMeter uses BSF. Likewise I'm subvscribed to Commons-dev. but well - that's just my opinion and the -1 should not be blocking. Just saying that I don't like the idea. snip/ Sure, and I'm not trying to get you to like it, rather to understand your initial response a little better. Thanks for elaborating. -Rahul cheers -- Torsten - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
