The current status document states that it is resolved that a-c is language
agnostic. There is no statement however about how a-c will manage the
multiple languages. So I've been musing...

1) One sub-project of a-c for each language, with each component effectively
a sub-sub-project within the language (eg.
commons.apache.org/java/collections)

2) One sub-project for each component ignoring language (eg.
commons.apache.org/collections). But then what happens if that component is
implemented in two languages?

This affects many things - how the mailing lists are structured, how the
website is structured, how the communities will form, etc.

I would like to see some clarification on this. The key aspect to me seems
to be the mailing list one:

Does it help to have C/C#/D/Perl/PHP/Java components on a shared mailing
list?
Or is per language better?
Or maybe we should have more mailing lists?

For example new mailing list groups could be formed along these lines:
a) Collections, IO, Lang, Pattern, Util, BeanUtils components from j-c (a
'Java core' list)
b) Betwixt, Digester from j-c, and components from XML-Commons (an 'XML'
list)
c) HttpClient and Net from j-c (a 'Networking' list)
d) Catch all for smaller components and the sandbox
(please don't debate the details of which component is in which (yet), its
an example!)

Now, I'm still only considering Java in these examples. This is because I
have real difficulty processing how non-Java code will fit in. Perhaps for
(a) it doesn't as thats very Java specific, but maybe for (b) and (c) it
does, because XML and Networking are more cross language concerns?

(To declare an interest for those who don't know, group (a) would be that
which would most affect me. Thus my proposal avoids me dealing with
non-java. But I'm proposing it because it seems to make some sense, not for
personal reasons)

IMHO, the good part about commons is the shared mailing list, but its also
the bad part. It strikes me that separation into smaller mailing lists
earlier in j-c's life might have been beneficial, even though the sense of
community seems to bind everyone to a single larger list.

And with mailing lists follows committer privileges, CVS structure, voting,
management etc etc.

Stephen


Reply via email to