On Sat, 1 Jan 2005, robert burrell donkin wrote:On 1 Jan 2005, at 11:52, Henri Yandell wrote:On Sat, 1 Jan 2005, robert burrell donkin wrote:
<snip>
So how should we do it under the assumption that everyone doesn't up for TLP? Do we add a jakarta-user and jakarta-dev mailing list that is the merger of N sub-projects and effectively another Commons, or just kill the N mailing-lists in favour of the commons lists and give CVS access to Commons committers to the N sub-projects?
the commons started out as an experiment. why not just start a new experiment?
the new experiment would not be a sub-project and not have any sub-project layer (in organizational terms). the only binding votes would be from jakarta pmc'ers and karma would be granted (upon request) to any jakarta committer who wished to contribute (by means of a status file).
I'm not sure what this consists of apart from adding a Components section to the nav section and putting a few things under it instead of Subprojects. Would we change the SVN structure in anyway? What actually would change? Just commit perms?
the major change would be organizational: they would no longer be sub-projects but products directly managed by the jakarta project. in practical terms, the major change noticable would be that any necessary VOTEs would happen on the pmc and all jakarta committers would be treated equally (karma granted on request). the rest could remain the same.
i would personally favour moving away from the division into sub-projects on the navigation bar into something more suitable as a directory or portal.
<snip>
i don't know how this will all work out in the longer term but it's closer to the preferred model than the mature sub-projects are now and so is a step in the right direction. maybe a little further along the process it'll be easier to see the best way forward from where we are then.
I'm always in favour of ways to take baby steps to good long term goals, but not sure what the steps would change here.
If, say, we change commit rights to BCEL, BSF, ECS, ORO and Regexp to any Jakarta committer, they'd still only be changed by people listening to the mail lists. If we offer commit to any Jakarta committer who asks, I suspect no one would ask.
most of these projects are mature with few reasons for further development. it is possible that with more liberal commit rights, one or two may come alive again but i'd say that the main motivation should be to provide an effective maintenance environment for mature code.
all of these have experienced issues with the sub-project organization model (since they have too few active sub-project committers to form a quorum). the products-within-project may turn out to be a better model.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
