On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote: ... > Other projects have now decided to create a sandbox, and it works quite > well. It has some advantages over the scratchpad: > > - it does not "pollute" the main repository space > - it does not force others to download it > > The drawbacks are still present: > > - it hides the works a bit more than with scratchpad > - it does not get tested as with current scratchpad > > Actually, if we think aboyt it, it does not really hide things much more > than scratchpad. And as Stefano said, if one thing should be in Cocoon, > it has to be integrated in the core ASAP, I agree. > > So, to try and bring together all positions, by fulfilling the *needs* > with a new implementation, I would propose (taking some points from > Jeff's proposal): > > - Cocoon moves scratchpad to a new CVS module cocoon-sandbox > under cocoon-sandbox/src/java/** > - We move all alpha blocks to cocoon-sandbox/src/blocks/** > - we add Forrest-based documantation to teh scratchpad and > each block > - for every piece of alpha-quality code (block, scratchpad segment), > we could have a status file (as Tony Collen suggested) in the > documentation indicating things like: > > - code proposal initiators > - description (eg links to mailing list discussions) > - lease expiry > > > This will IMHO: > > - make alpha code clearly marked (I'm happy) > - keep possibility of sperimenting out of the core > (Jeff, Ovidiu and I are happy) > - keep sandbox out of main CVS module and make code > not rot (Stefano's happy)
How about making one modification to this proposal... Host the Cocoon sandbox at Sourceforge, instead of Apache. Call it cocoon-contrib or something. Why? Because then anyone can participate. It tears down any perceived barrier between cocoon-dev and cocoon-users. Best of all, when code eventually is 'promoted', there is a strong possibility of gaining new Cocoon developers. Think of it as housing "alpha committers" as well as "alpha code". The root problem is that Cocoon has more code than code maintainers. The long-term solution is not to juggle the code more effectively, but to gain more committers. THAT is why I think a cocoon-contrib @ sourceforge would be a win in the long run. Thoughts? --Jeff > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > ---------------------------------------------------------------------
