You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/01/17 11:44:42 UTC
[picky-mode] scratchpad 2.0
Ok guys,
I'm turned my picky-mode on and I'm going to be a pain in your ass for a
while :)
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?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [picky-mode] scratchpad 2.0
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: "Apache Cocoon" <co...@xml.apache.org>
Sent: Thursday, January 17, 2002 11:44 AM
Subject: [picky-mode] scratchpad 2.0
>My proposal turn an individually-oriented R&D location into a
>community-oriented R&D location.
This makes me think that it could be an idea to informally nominate
developers to basic community roles.
For example, IMO it's important that we show that we value patches. It's one
of the basic rules of opensource.
It would be nice if someone is appointed to check that status, changes, etc
are uptodate and that people carry on tasks, like the ones Sourceforge
provides.
> 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 think it's cool.
I would suggest that each area has its own build.xml, and that it's
referenced from the main one.
If the interactive build patch is committed, I can add a whiteboard build
that exposes these builds.
In this way, to try whiteboard stuff you just need to select a build.
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [picky-mode] scratchpad 2.0
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Stefano Mazzocchi wrote:
> > 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]/
>
> 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.
+10! Second that! Add also Gerhard's request to this:
> From: Gerhard Froehlich [mailto:gerhard_froehlich@at.ibm.com]
...
> Because a cool build.xml is missing, where you can build and integrate
> the scratchpad easily.
> It's a PITA when you have to modify the cocoon.xconf and cocoon.roles
by
> hand each time when you build the scratchpad. I got really angry two
days
> ago when I integrated my JispFilesystem Store + extra config files
into
> the scratchpad, because it is so circumstantial.
>
> What I did, I added a include.scratchpad.lib switch into the build.xml
> file to include at least the scratchpad libs into the war file.
>
> What we need is a sophisticated build file. And I address this to
seniors
> in this project.
...
And we have an easy way to develop/try knew components (like coming
MathML).
> - 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.
Agreed.
> Now +1 for the install / description files.
+1, Same here.
>
> Sylvain
>
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [picky-mode] scratchpad 2.0
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Re: [picky-mode] scratchpad 2.0
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> 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!
well :)
> > 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.
good point.
> > 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.
yes, good point.
> 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.
Oh, one doesn't rule the other out.
> 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?
when the community decides so, after a votation.
> 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.
yes.
Ok, I'll try to come up with 'rules for somewhat-evolutionaries' real
soon.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [picky-mode] scratchpad 2.0
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org