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. 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. > - 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? > - 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? 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. > - not have a sandbox does that mean: use the jakarta sandbox if every needed? > - 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... - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
