cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Scratchpad leases (Re: [RT] what cocoon is doing wrong)
Date Wed, 26 Feb 2003 04:57:51 GMT
On Tue, Feb 25, 2003 at 05:37:07PM -0500, Berin Loritsch wrote:
> Nicola Ken Barozzi wrote:
...
> >>I repeat my proposal to kill the scratchpad
> >
> >
> >Hmmm... how could we have done the flow without the scratchpad?
> >Do you really think that Schecoon could have been done in head?
> >
> >Make the scratchpad-blocks dir, and that will automatically solve many 
> >of these problems and clear the scratchpad.
> >
> >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.

> * 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?

> * 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.

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.


--Jeff

Mime
View raw message