Stefano Mazzocchi wrote: > > Ok guys, > > I'm turned my picky-mode on and I'm going to be a pain in your ass for a > while :) >
Hmm, I have to find the "turn-off" button somehow. > I'm sure all of you will be delighted to hear this :) Yupp, absolutely. Life would be so boring without it! Really! > > Anyway, wondering around our nice and great CVS module (looks *much* > better now, big thanks to Giacomo and Carsten for their wonderful work!) > I found the 'scratchpad' area a nice concept, but, resonating with > Gianugo, it is very likely to become the 'place for forgotten code'. > > well, 'forgotten' is not the right word: let's say > 'individually-developped', which is better, but not that much. > I agree. > My personal impression looking into scratchpad is that I see lots of > potentials, but I hardly see a way to try them out. Even less, a way to > help. > Yes. > I know I can write to the author and ask, but what about somebody that > just grabs the CVS and wants to try new things out? > > Don't rule them out: they are the very spirit of innovation! > > I think that, as it is, "scratchpad" is an invidually-oriented tool. The > very name says it! > > My proposal turn an individually-oriented R&D location into a > community-oriented R&D location. > > How? a few suggestions > > 1) let's rename "scratchpad" into "whiteboard"! > > 2) each cocoon developer has the right to ask for a "whiteboard area" > without requiring a votation, thus the directory structure will be as > such > > /src/whiteboard/[area]/ > Hm, I'm not sure if this is a good idea. Perhaps it will work, perhaps we end up by having even more areas with individual code as everyone starts his one area then. > 3) the /whiteboard directory contains an XML file that indicates the > 'owner/s' of the area, along with a brief description of what is > supposed to do. > +1 > 4) each area contains an 'INSTALL' file that indicates how to install > the 'area' on top of Cocoon and try it out. > +1 > What do you think? > I don't believe that renaming the directory, writing an INSTALL doc and separating the scratchpad into different areas will really decrease the individualism of this area. The main problem is that the components contained in the scratchpad are not so easy to install and test. Now the usual procedure is to build the normal webapp, "deploy it somehow" and then manually add the configuration for the scratchpad component you want to look at. Now if you change something, you propably have to do this all over again. This is very time consuming. Even worse, for some components you have to change classes from the main area. You can't do these changes in the main area for obvious reasons, but how can you maintain it in the scratchpad area? Duplicate code? I really don't know. So in order to integrate new functionality and to share it, it seems much easier to start developing in the main area. Put putting experimental code in the main area will perhaps break the application for a period of time, it might be that the interfaces change etc. And another question is, when can things be moved out of the scratchpad? So, now after I have turned around 360 degrees, we could try your proposal and see what we end up with. We can then later on still change the rules. Anyway, I would suggest that we try to minimize the changes until we have 2.0.1 out. Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
