cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Date Wed, 26 Feb 2003 09:39:21 GMT
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.



> -- 
> Nicola Ken Barozzi         
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------

View raw message