Phil Steitz wrote:
Hopefully we can keep it at a point where the groups are really just
there to refine the flow of mail, not to separate it. HttpComponents
is an example of this (though not a good one as most of its components
came from HttpClient). WebComponents (formerly hoped to be known as
Silk) is another example.
Commons would be groupalized out.
Not sure I understand exactly what you mean here, but if it means
breaking commons up - even the list - I think we should think very
carefully about that. From what may be a selfish perspective - and
which I will back off from if the rest of the community feels otherwise
- I think getting feedback from the full group of commons committers and
voluneers *really* helps those of us who work on commons components. I
am afraid that if we break up the dev list and we don't all just agree
to subscribe to all of the sublists (really defeating the purpose), we
will both have a harder time building community around components and we
will lose some valuable feedback. We will also have less collective
energy to apply to things like the site, how we think about versioning
and releases, etc. We are developing a pretty good body of collective
experience developing small java components and I think that if we
"split up" now we may be losing something.
I believe that this plan only works if we are prepared to have multiple
mailing lists. Try merging velocity, httpclient, taglibs,... all into
the commons list and its just ridiculous.
The question is how to break down the groupings. And how big should they
be. One rule would be that a component is only in one grouping.
For example:
- HttpComponents
- WebComponents
- LibraryComponents (narrowAPI-deep)
- BaseComponents (broadAPI-shallow)
site and build discussions can occur on a shared list.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
