Bertrand Delacretaz wrote: > > I agree very much with Nicola, basically "only one implementation of > something in the main part of the CVS tree, variants live in the > scratchpad until voted to be integrated or discarded". > I absolutely agree, too.
> In the same spirit, it might be good to ask for a vote (or at least a > discussion) before adding any new block to the main code, to help keep > things focused. > Yes, we must find a way to handle blocks and to decide when a new block should be created and when not. Currently it's possible to create a block if you have one single class that doesn't belong to the core. So you start a block with this single class, a configuration for it and hopefully a documentation. Now, as Nicola explained, the sandbox (or scratchpad) area is very important and I think we should think about creating a cocoon-sandbox repository and move the scratchpad into it. Currently, if the scratchpad doesn't build for whatever reason, cocoon doesn't build (ok, you can exclude it etc.). And the scratchpad is part of the release, and I'm not sure if it's the best idea to include it as if it's available in a release it will be used, nomatter what the docs say. I think, for cocoon 2.2 with the "real blocks" we need to think about our cvs strategy anyway. Currently, we agreed to create a new cvs repository for each new major version, so we would have a cocoon-2.2 repository. But what about the blocks, they are (or should be?) independent of the cocoon version, so it doesn't make sense to have them in cocoon-2.1 and cocoon-2.2 and get totally confused about when to apply what in which repository. As we will be releasing 2.1 soon we have to think about this so that we can start with 2.2 painlessly (regarding cvs). What do you think? Carsten
