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 :)
You do it so well ;) > I'm sure all of you will be delighted to hear this :) > > 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. > > 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. > > 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]/ > > 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. > > 4) each area contains an 'INSTALL' file that indicates how to install > the 'area' on top of Cocoon and try it out. > > What do you think? > I agree with the goals you want to achieve (community work area), but I'm surprised by the solution you propose. Segmenting the scratchpad (or whiteboard) will IMO lead people to work in their area only, and be less tempted to see what's happening in other areas. This will likely lead to duplication of efforts and integration problems (know Gump ?). Look for example at log4j's CVS : there are some "contrib/JohnDoe" directories where some obviously dead code lies in. Now segmentation can be needed for proposals that either are prototyping areas, or either impact the existing structure of Cocoon (backward-incompatible changes). This what Ant and Avalon have with the "proposal" directory. So what about 3 levels : - src : official distribution. - whiteboard : new components / extensions compatible with the current distribution, but not (yet) officially in. - proposal/[area] : "thou who enters in, abandon all hope" ;) Code may not even compile ! There may be a build.xml, duplicated libs, forks of existing code, etc. Important point : forbid [area] names to be people's name. We're all working on Cocoon, and what identifies who's done what is the @author in sources. People should not build their private house with fences around in this community. Now +1 for the install / description files. Sylvain -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
