Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E5C752E.3050809@apache.org>
Date: Wed, 26 Feb 2003 09:05:02 +0100
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: [Proposal] Cocoon Sandbox ( Re: Scratchpad leases )
References: <3E5BBC11.5050205@apache.org> <3E5BEA9E.8010709@apache.org>
 <3E5BF013.6020900@apache.org> <20030226045751.GA475@expresso.localdomain>
In-Reply-To: <20030226045751.GA475@expresso.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Jeff Turner wrote, On 26/02/2003 5.57:
> On Tue, Feb 25, 2003 at 05:37:07PM -0500, Berin Loritsch wrote:
> 
>>Nicola Ken Barozzi wrote:
...
>>>Let's KISS. Let's start with the obvious. Move the scratchpad into 
>>>scratchpad-blocks and see what's left. We may be surprised.
> 
> +1
>
> ...
>>What would removal of the Scratchpad force on the community?
>>
>>* More controlled innovation.  Instead of anybody using it as their
>>  personal playground, it would force the development to be more in
>>  the face of the community.
> 
> Hence schecoon would have been shot down in flames, as people -1'ed it on
> the syntax.

exactly.

>>* Better concept of exactly what is in Cocoon.  After not being active
>>  for a while and comming back, I don't even recognize the project.
>>  How many of the current developers know *all* of what is in the
>>  CVS archive?
> 
> Why would anyone not interested look in the scratchpad?

And to reply to the first question of this section: what is Cocoon?
Cocoon is in src/blocks and src/java. That is Cocoon. Or at least it 
should be... se below.

>>* If the community doesn't want to support it, move it someplace else.
>>  IOW if the community doesn't want some code in the main trunk it is
>>  for a very good reason.  The proposing developer would be encouraged
>>  to incubate the project elsewhere.
> 
> Playgrounds *have* to exist.  The question is, do they happen in the
> scratchpad or on someone's hard disk.  At least in the scratchpad, there
> is a chance of half-baked code inspiring others, and forming a nucleus
> for further development.

+q

> I agree, there is a real problem in that scratchpad code tends to hang
> around in limbo forever, never accepted nor rejected.
> 
> So how about assigning each scratchpad module a "lease"; being a
> predefined period (say 3 months) after which the code's presence in CVS
> must be reviewed.  When the lease expires, a vote is held, and the code
> either becomes official, or is rejected, or has the lease renewed.
> 
> For every unit of alpha-quality code (block, scratchpad segment), we
> could have a status file (as Tony Collen suggested) indicating things
> like:
>   - code owners (cocoon-dev is not the owner yet)
>   - description (eg links to mailing list discussions)
>   - lease expiry
> 
> Managed inclusion rather than exclusion.

Yes, this sentence is a good explanation :-)

I have slept over it, and I start to feel that Stefano implies that all 
that is in xml-cocoon2 is Cocoon... which of course is the most obvious 
thing.

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)

So, does this make sense?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------