<snip/>
Scratchpad considered harmful -----------------------------
I proposed to remove the scratchpad and no consensus was reached. I try again but this time harder: I think the scratchpad is harmful.
Reasons:
1) for non-core stuff, alpha blocks will do just fine and will even keep libraries out of the way.
I agree *only* if you put them in a separate dir. Test code with normal code is even more *harmful* than dead code.
We need to tame the mess. See below.
2) if you want to try things around with core stuff, I *WANT* you to do it on the head. It's called 'continous integration'. No, dude, I won't make it easier for you, I want it to make it harder so that everybody sees what you're doing and can improve on it.
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.
Taming the Mess ---------------
The Cocoon CVS structure is a mess. We have source directories all over the place, JARs all over the place (some of which are duplicates), and it seems like you need a Ph.D. just to understand what is going on where.
Why is this the case?
* Several scratchpad ideas/concepts would have been better implemented as a separate project that *depended* on Cocoon. * Scratchpad allowed uncontrolled innovation. That has its plusses and minuses. It allows us to attempt to use bleeding edge technologies, with the understanding that the dependency libraries would be changing underneath us. * Things linger in scratchpad longer than they should. A concept gets started and then the community (or developer) gets sidetracked on something else.
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. * 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? * 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.
I agree that we need to KISS. The problem is that our definitions of simple do not mesh. What we need is a simple way for the developers/ users to know how to embrace and extend Cocoon for their purposes. At this very junction, we don't have it. Through a long iterative process of doing things one step at a time, we can get there.
I think you might be optimistic with the scratchpad-blocks. I think there needs to be a little better education on the CVS structure, and why things are the way they are. If we as a community decide that things need to change, we can at least have a better understanding of the implications of that change.
