cocoon-dev mailing list archives

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

Wow, it's the first time I see FS applied to community dynamics. You 
guys keep surprising me :)

I want the scratchpad out of the main cocoon CVS module (now 
xml-cocoon2, in the future just 'cocoon').

Why? because I want to reduce the number of core dependencies we have 
since the whole thing it's becoming unmanageable.

There are two sort of things in the scratchpad:

  - alpha blocks
  - alpha core stuff

I think we all agree in moving the scratchpad alpha blocks in the blocks 
directory and mark them as alpha. we'll add a block descriptor file that 
indicates their status and we'll be happy.

This leaves us with the alpha core stuff.

Many of you say that Schecoon would not have happened if it wasn't for 
the scratchpad. I don't see this. Nobody helped Ovidiu and the scheme 
syntax argument was discussed over email, not CVS. He proposed, we 
commented, some disliked, some liked, some ignored, some backed up. The 
fact that code development happened on our CVS did it really made a 

Only one: we saw commit messages. We followed development.

Now, did you guys ever heard about a nice CVS concept called 
"branching"? Ovidiu wanted to work on some cocoon internals, wanted to 
have a place to try things and didn't want to step on our toes, so he 
should have asked for a branch and we would have given it to him.

the scratchpad is a lazy version of the same concept, too bad that when 
developers use branches the tend to go quickly to the point where they 
can merge it with HEAD, unlike the scratchpad that is *already* in head, 
so it will be picked up anyway by the release, even if marked sideways.

I want people to work on HEAD so that they feel the pressure and do a 
better job.

If I refactored the build on a branch (or even worse, on another CVS 
module), how many of you would have tried it out and debug it?

Martin Holz wrote:
 > P.S : Improving the build system is really worth some temporary
 > inconvenience. Thank you very much.


Now, about the alpha-committers: the scratchpad creates one-man-shows 
even if we know that our committers have an extensive log of being able 
to work with others.

If you open up the gates to everyone, do you really think that this will 
help finding new developers for this community? I strongly doubt it.

I'm positive it will generate tons of half-baked concepts and components 
mockups, but it will reduce the filtering that community performs and 
will remove the incentive for them to work harder to gain access to CVS.

The overall quality of code will be much lower and they will feel 
confortable with this since nobody will (could) complain for political 

The result will be that we won't ship anything from that since we will 
fear of insulting some of those one-man-shows.

So, at the end, you have simply created a poor-quality collection of 
one-man dumped and half-baked efforts. Also known as the result of the 
"Sourceforge Effect".

Sure, one of a thousands might be worth considering. But somebody will 
have to spend his energy finding out which one of these is worthwile and 
since cocoon users and devs will concentrate here, the amount of energy 
to screen those efforts will be very low.

                                 - 0 -

I continue to propose to kill the scratchpad for alpha core code without 
creating an alternative.

Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine necessitate [William of Ockham]

View raw message