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:
On 27 Dec 2004, at 11:35, Torsten Curdt wrote:Noel J. Bergman wrote:
<snip>
There has been
some suggestion that they be cleaned up by migrating them to some other
domain to be mothballed. The code, web site, and mailing list archives
would be preserved, and could be restored at such time in the future when a
community might arise.Hmm... the question is whether we really *can* mothballing them. IMHO too many projects rely on them. It's an important piece of technology. At least bugfixes need to be applied. FWICS migration costs (e.g. to asm) are fairly high. There *are* people that have patches in the queue.
i would like to suggest again something that costin suggested a long while ago now: for mature sub-projects we remove the extra layer and organize them directly under jakarta. so rather than being run as sub-projects with their own separate committer lists, the jakarta community runs them directly.
Effectively I'm +1 on that. I think of it as hope that enough of the self-contained projects ask to move to TLP and then we promote Commons components to sub-project level and make CVS Jakarta-wide.
i'm not sure that moving commons components to sub-project level would be a good idea. IMHO it would be far better to leave them exactly as they currently are: components distributed by jakarta. i can see no benefits from designating them as sub-projects. even the name has become more than a little tainted.
Well, the impossible dream runs:
1) Various things goto TLP.
2) We're left with Commons, various component like subprojects (ORO/Regexp/ECS etc)
3) Promote Commons components to Jakarta level
4) Rename Subprojects to Components
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?
i'd say leave the mailing lists for now (there are infrastructure implications) but let's give the mature sub-projects you listed earlier a choice: join the new experimental not-sub-project or move to TLP status.
Not a choice I can give. I can dream of TLPness, but as far as I know the community does not want to be pushing to TLPness.
Interestingly, time is working against us. If we view TLP-ers as liberal and Jakarta-ers as conservative (not politically, just in approach to the idea of location), then as time goes by the community is more and more against pushing for TLP :)
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.
Hen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
