Board report done - now I can irritate you all on these threads again :)
On Tue, 14 Mar 2006, robert burrell donkin wrote:
On Tue, 2006-03-07 at 19:13 +0000, Stephen Colebourne wrote:
Reposted (edited) from original commons proposal.
Currently this proposal has general, though not unanimous, support.
A vote thread may follow this thread if the mood remains positive.
i'm a little unsure whether this will turn out for better or worse but
if people out there have energy, i'm willing to give it a go. time's
probably right for a little innovation and experimentation.
i like the idea of tagging emails better: a single list with cool server
side filtering and metrics. we don't have the technology for this yet so
i'm willing to see the mailing lists split so long as people would be
willing to consider coming back if it every arrives...
I hereby propose the creation of a new Jakarta entity named 'Jakarta
Language Components'.
This will be formed from the following codebases:
[lang]
[io]
[collections] - expected to divide
[primitives]
[codec]
[id] - on exit from sandbox
[beanutils] - logging to be removed
The following are invited to join if their communities desire:
[oro]
[regexp]
[cli]
Jakarta Language Components mission:
'Enhancing Java SE'
Jakarta Language Components will:
- develop multiple independent components
yep
- each component will have no dependencies
- each component will have no configuration
perhaps a description may be better than a proscription: charters are
bad since they need votes and formalism. groupings should be less formal
and more social than sub-projects.
Not sure if you're saying this, but +1 to having no formal charter - just
an informal description.
i think groupings will only work if the formal structures required
(voting, karma, websites and so on) can be kept fixed and cross grouping
so that groupings can be more fluid.
+1
- each component provides an extension to the JavaSE
- code judged by would it be out of place in the JavaSE
probably the wrong test: some of the stuff that's included is pretty
controversial and grows in scope all the time. i'm not sure that this is
really what a lot of the extra rubbish is wanted: eg logging, crypto,
sql, corba, swing.
isn't it only really the lang, util, io and beans packages that are
really of interest?
+1. 'core of JavaSE' ?
- a component typically has a broad API (many callable methods)
- each method typically does relatively little processing
KISS: not needed in a charter
might be better to be descriptive: offer a separate positive description
of an architypical component. this can be longer and can be amended more
easily. grouping ethos document, perhaps?
- have mailing lists (language-user/language-dev)
is there any need for a another user list?
Also, why cause users pain while we experiment. How about we do the -dev
list, and see how the -user list goes?
given smaller mail volumes and the nature of the audience for these
components (java developers), i think it would be better to retain a
common user list but encourage posting by users to the dev list.
the commons was more active when there was no user lists. i'd like to
propose we try that again for this new grouping. if a user list proves
necessary then it can easily be added later.
Ah. I thought you were suggesting that they would continue to use
commons-user. :)
I'm +1 to commons-user. I'm only +1 to not havin a user list if we get the
commits/wiki/jira out of the user's face.
- not have a sandbox
does that mean: use the jakarta sandbox if every needed?
Pretty sure it does.
- use [EMAIL PROTECTED] ML (new) for cross group issues
general would feel better (to me) for discussing cross group issues but
maybe dev might be needed for votes later...
Yep. Re-word as:
- use Jakarta wide lists for cross group issues.
We can modify what those are if we think that general@ is overwhelmed by
Jakarta and we'd like it to be more pan-Apache Java or general-interest.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
