single component mailing lists
------------------------------
i think that single component mailing lists have not proved very successful.
I completely disagree. As the HttpClient 2.0 release prime, I am disheartened that you feel that way.
Please, subscribe to the httpclient list. It would be no different for those who wanted all traffic to just subscribe to all lists. You just have to subscribe once and thats it. But for those who want to focus on particular components, there is no effictive way to do that on a single list. Filtering is not effective as it relies on putting [name] in the subject, which is inadequate.
not only are they unpopular with the components themselves but they are hard for outsiders to monitor. i (for one) have no idea about what's happening in httpclient and i cannot effectively supervise them.
The other major benefit of list partitioning is the archives. It sucks finding somthing particular in the archive of commons, or just browsing last weeks traffic, but is simple on a dedicated list.
If you are interested in HttpClient, and want to participate, please, just subscribe to the list. You have the power.
This was a grey area. When HttpClient got back to critical mass where we could sustain our own votes, we started voting on our own. I think that this is just natural evolution. We have been voting on releases, release plans, committers and are about to vote on some amendments to coding style. We are doing our best to do everything right and you are just a link away from joining in: mailto:[EMAIL PROTECTED]
when we decided to push them out onto their own list, i thought that all votes were supposed to remain on the main list. i don't recall seeing any VOTEs on this list about new committers or about releases. (i'm not saying that there's been any impropriety - just that if there was, there's no way that i'd know.)
The best voting solution is not to merge httpclient traffic back to commons but to create a dedicated VOTE list. Committers should be subsribed to as as part of account creation and contributors could subscribe to if they are interested. Just think how nice that would be for the PMC folks trying to monitor what was going on without having to sort through 5000 messages a month.
possible component groupings
----------------------------
BeanUtils, CLI, Collections, Discovery, Lang, Logging should have enough momentum to a become a viable core grouping.
JXPath, jelly, betwixt, digester may be big enough to become a viable xml grouping
pool, DBCP could fit together into a cache group - but i think that it would be too small to be viable.
httpclient, latka, fileupload could fit together into a http group - but again, probably too small
Logical or not, these groupings are arbitrairy. Why enforce a grouping? Give users the finest granularity possible, and then they can choose their own group of lists to join based on their interests. And have trivial filtering to boot. If you REALLY wanted to have groupings, you could compose them from the fine grained lists. A meta list of lists as it were, where the meta list would subscribe to other lists and the users could subscribe to the meta lists or the fine grained lists as it suited them.
-jsd
Jandalf
Jeff Dever
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
