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 difference?
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.
See?
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 correctness.
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 <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
