cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [picky-mode] scratchpad 2.0
Date Thu, 17 Jan 2002 11:19:41 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message