You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2004/02/29 18:53:08 UTC
RE: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml DocumentHelper.java
As far as I know (from my weak memory :) ) there hasn't been a vote
at Cocoon about "accepting" this block.
So, can you please enlighten us (or only me?) about the use of this
block for Cocoon and why you want to move it here?
I'm really worried that everyone starts a new block whenever he
thinks it's right to do without asking anyone (This is not targetted
at you Gregor.). I did this myself, yes.
But I think we should sometime really start to discuss new blocks,
otherwise we get burried under too many blocks noone maintains.
In fact a block is a new subproject that perhaps should go through
incubation etc.
Carsten
> -----Original Message-----
> From: gregor@apache.org [mailto:gregor@apache.org]
> Sent: Sunday, February 29, 2004 6:35 PM
> Log:
> new workflow block from lenya.
>
> see
> http://nagoya.apache.org/eyebrowse/BrowseList?listName=lenya-d
ev@cocoon.apache.org&by=thread&from=653774 for a discussion and vote on
this.
>
> the block is marked unstable.
>
RE: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml DocumentHelper.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Thanks for the answer, Gregor.
Some comments inline:
Gregor J. Rothfuss wrote:
>
> when we started this functionality, there was no workflow
> engine around that specifically targeted the sane and common
> 80% of the requirements.
> so we wrote our own :) recently, some cocooners showed
> interest in the code and making it into a block seemed the
> right way to make more people aware of this code base. when
> andreas designed this workflow code, he tried to seperate
> generic workflow functionality from lenya-specific functionality.
>
> generic:
> http://cocoon.apache.org/lenya/apidocs/org/apache/lenya/workfl
> ow/package-summary.html
>
> lenya:
> http://cocoon.apache.org/lenya/apidocs/org/apache/lenya/cms/wo
> rkflow/package-summary.html
>
If this block stays in Cocoon you have to rename the packages
to org.apache.cocoon.*
>
> > But I think we should sometime really start to discuss new blocks,
> > otherwise we get burried under too many blocks noone maintains.
> > In fact a block is a new subproject that perhaps should go through
> > incubation etc.
>
> i think that would be overdoing things a bit. but i agree
> that a way to deal with new blocks needs to be found. one
> goal of lenya is to make more of its functionality into
> blocks (revision control?, access control?, editor
> integration? etc). whether those should be part of cocooon or
> whether lenya should mirror the cocoon block architecture and
> have its own is also an interesting question. in any event,
> breaking it up in blocks makes lenya easier digestable for
> interested parties :)
>
Yes, sure. I personally tend that it's better to first create
the blocks at lenya and only if it really makes sense move it
to Cocoon. We had the same problem years ago with general
components that were moved from Cocoon to Avalon. Although
this was from a theoretically POV the best thing to do, it
created a mess and we still suffer a little bit from this move.
I think (today), the code should stay where the community really
is - even if some people say "Hey, cool, I'm interested" it doesn't
mean that they will really participate later on.
In any case, please ask the next time on the Cocoon dev list
before adding a new block.
> from what i understand, some issues with blocks won't be solved in the
> 2.1 timeframe, and require 2.2. i wonder what easy steps
> could be taken in 2.1?
>
I think you could use the same build system Cocoon is using with
separate directories. Perhaps there is a better way :)
Carsten
Re: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml
DocumentHelper.java
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Carsten Ziegeler wrote:
> As far as I know (from my weak memory :) ) there hasn't been a vote
> at Cocoon about "accepting" this block.
you are right, there wasnt. in the thread on lenya-dev it was opined
that this would not be necessary.
> So, can you please enlighten us (or only me?) about the use of this
> block for Cocoon and why you want to move it here?
when we started this functionality, there was no workflow engine around
that specifically targeted the sane and common 80% of the requirements.
so we wrote our own :) recently, some cocooners showed interest in the
code and making it into a block seemed the right way to make more people
aware of this code base. when andreas designed this workflow code, he
tried to seperate generic workflow functionality from lenya-specific
functionality.
generic:
http://cocoon.apache.org/lenya/apidocs/org/apache/lenya/workflow/package-summary.html
lenya:
http://cocoon.apache.org/lenya/apidocs/org/apache/lenya/cms/workflow/package-summary.html
> But I think we should sometime really start to discuss new blocks,
> otherwise we get burried under too many blocks noone maintains.
> In fact a block is a new subproject that perhaps should go through
> incubation etc.
i think that would be overdoing things a bit. but i agree that a way to
deal with new blocks needs to be found. one goal of lenya is to make
more of its functionality into blocks (revision control?, access
control?, editor integration? etc). whether those should be part of
cocooon or whether lenya should mirror the cocoon block architecture and
have its own is also an interesting question. in any event, breaking it
up in blocks makes lenya easier digestable for interested parties :)
from what i understand, some issues with blocks won't be solved in the
2.1 timeframe, and require 2.2. i wonder what easy steps could be taken
in 2.1?
-gregor
--
Gregor J. Rothfuss
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
Re: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml
DocumentHelper.java
Posted by Michael Wechner <mi...@wyona.com>.
Carsten Ziegeler wrote:
>As far as I know (from my weak memory :) ) there hasn't been a vote
>at Cocoon about "accepting" this block.
>
>
yes, not that I know
>So, can you please enlighten us (or only me?) about the use of this
>block for Cocoon and why you want to move it here?
>
>
Well, I actually thought that we would maintain the block within Lenya
first and then move
it to the Cocoon module. But I guess Gregor's intention was meant to be
good in order to facilitate
the developement also for "Cocoon developers only" from the very beginning.
>I'm really worried that everyone starts a new block whenever he
>thinks it's right to do without asking anyone (This is not targetted
>at you Gregor.). I did this myself, yes.
>But I think we should sometime really start to discuss new blocks,
>otherwise we get burried under too many blocks noone maintains.
>
>
agreed
>In fact a block is a new subproject that perhaps should go through
>incubation etc.
>
>
Well, Lenya definitely is going to use this block, but as I said it
doesn't have to be maintained within
the Cocoon module.
I would suggest that we discuss it right now and depending on the
general interest we either let it
stay or move it into the Lenya module. Makes sense?
btw, in case people would be agreeing on adding it to Cocoon, then I
guess the Java package should be renamed.
Michi
>Carsten
>
>
>
>>-----Original Message-----
>>From: gregor@apache.org [mailto:gregor@apache.org]
>>Sent: Sunday, February 29, 2004 6:35 PM
>> Log:
>> new workflow block from lenya.
>>
>> see
>>http://nagoya.apache.org/eyebrowse/BrowseList?listName=lenya-d
>>
>>
>ev@cocoon.apache.org&by=thread&from=653774 for a discussion and vote on
>this.
>
>
>>
>> the block is marked unstable.
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml
DocumentHelper.java
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Carsten Ziegeler wrote:
> As far as I know (from my weak memory :) ) there hasn't been a vote
> at Cocoon about "accepting" this block.
you are right, there wasnt. in the thread on lenya-dev it was opined
that this would not be necessary.
> So, can you please enlighten us (or only me?) about the use of this
> block for Cocoon and why you want to move it here?
when we started this functionality, there was no workflow engine around
that specifically targeted the sane and common 80% of the requirements.
so we wrote our own :) recently, some cocooners showed interest in the
code and making it into a block seemed the right way to make more people
aware of this code base. when andreas designed this workflow code, he
tried to seperate generic workflow functionality from lenya-specific
functionality.
generic:
http://cocoon.apache.org/lenya/apidocs/org/apache/lenya/workflow/package-summary.html
lenya:
http://cocoon.apache.org/lenya/apidocs/org/apache/lenya/cms/workflow/package-summary.html
> But I think we should sometime really start to discuss new blocks,
> otherwise we get burried under too many blocks noone maintains.
> In fact a block is a new subproject that perhaps should go through
> incubation etc.
i think that would be overdoing things a bit. but i agree that a way to
deal with new blocks needs to be found. one goal of lenya is to make
more of its functionality into blocks (revision control?, access
control?, editor integration? etc). whether those should be part of
cocooon or whether lenya should mirror the cocoon block architecture and
have its own is also an interesting question. in any event, breaking it
up in blocks makes lenya easier digestable for interested parties :)
from what i understand, some issues with blocks won't be solved in the
2.1 timeframe, and require 2.2. i wonder what easy steps could be taken
in 2.1?
-gregor
--
Gregor J. Rothfuss
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml
DocumentHelper.java
Posted by Geoff Howard <co...@leverageweb.com>.
Carsten Ziegeler wrote:
>As far as I know (from my weak memory :) ) there hasn't been a vote
>at Cocoon about "accepting" this block.
>
>So, can you please enlighten us (or only me?) about the use of this
>block for Cocoon and why you want to move it here?
>
>I'm really worried that everyone starts a new block whenever he
>thinks it's right to do without asking anyone (This is not targetted
>at you Gregor.). I did this myself, yes.
>But I think we should sometime really start to discuss new blocks,
>otherwise we get burried under too many blocks noone maintains.
>In fact a block is a new subproject that perhaps should go through
>incubation etc.
>
>
I think until we have real binary (deploy time, not compile time)
blocks, and an infrastructure to support mini-subprojects out of the
core, the reality is that we have to keep all this stuff in the current
cvs.
Personally I'm quite interested in a workflow block, so had we discussed
it I'd have been in favor of it for just the reason they mention: Lenya
is not the only place it's useful.
Geoff
>>-----Original Message-----
>>From: gregor@apache.org [mailto:gregor@apache.org]
>>Sent: Sunday, February 29, 2004 6:35 PM
>> Log:
>> new workflow block from lenya.
>>
>> see
>>http://nagoya.apache.org/eyebrowse/BrowseList?listName=lenya-d
>>
>>
>ev@cocoon.apache.org&by=thread&from=653774 for a discussion and vote on
>this.
>
>
>>
>> the block is marked unstable.
>>
>>
Re: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml
DocumentHelper.java
Posted by Michael Wechner <mi...@wyona.com>.
Carsten Ziegeler wrote:
>As far as I know (from my weak memory :) ) there hasn't been a vote
>at Cocoon about "accepting" this block.
>
>
yes, not that I know
>So, can you please enlighten us (or only me?) about the use of this
>block for Cocoon and why you want to move it here?
>
>
Well, I actually thought that we would maintain the block within Lenya
first and then move
it to the Cocoon module. But I guess Gregor's intention was meant to be
good in order to facilitate
the developement also for "Cocoon developers only" from the very beginning.
>I'm really worried that everyone starts a new block whenever he
>thinks it's right to do without asking anyone (This is not targetted
>at you Gregor.). I did this myself, yes.
>But I think we should sometime really start to discuss new blocks,
>otherwise we get burried under too many blocks noone maintains.
>
>
agreed
>In fact a block is a new subproject that perhaps should go through
>incubation etc.
>
>
Well, Lenya definitely is going to use this block, but as I said it
doesn't have to be maintained within
the Cocoon module.
I would suggest that we discuss it right now and depending on the
general interest we either let it
stay or move it into the Lenya module. Makes sense?
btw, in case people would be agreeing on adding it to Cocoon, then I
guess the Java package should be renamed.
Michi
>Carsten
>
>
>
>>-----Original Message-----
>>From: gregor@apache.org [mailto:gregor@apache.org]
>>Sent: Sunday, February 29, 2004 6:35 PM
>> Log:
>> new workflow block from lenya.
>>
>> see
>>http://nagoya.apache.org/eyebrowse/BrowseList?listName=lenya-d
>>
>>
>ev@cocoon.apache.org&by=thread&from=653774 for a discussion and vote on
>this.
>
>
>>
>> the block is marked unstable.
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
>
>
Re: Accepting new blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 1 mars 2004, à 11:13 Europe/Zurich, Andreas Hartmann a écrit :
> Bertrand Delacretaz wrote:
>
> [...]
>
>> Seeing how hard it is to retrofit tests and docs to existing blocks,
>> maybe we should require the following for any new non-scratchpad
>> block:
>> -samples
>> -automated tests
>> -documentation (in the block itself, I don't think our docs structure
>> makes it easy to integrate docs from blocks)
>
> What documentation format would be required here?
I don't think any mechanism is in place currently to integrate
documentation from blocks into the main docs. If I'm right, either
something must be created, or we must accept whatever the blocks
creators provide, as long as it gives sufficent info about the block.
Good self-documenting samples might be ok for simple blocks.
> Does it make sense to use the Forrest format (how
> would it be rendered)?
You could probably use the pipelines currently used to render docs
locally. But if would be better to find a simple way to integrate
blocks docs into the main docs, unfortunately I cannot help with this
ATM.
-Bertrand
Re: Accepting new blocks
Posted by Andreas Hartmann <an...@apache.org>.
Bertrand Delacretaz wrote:
[...]
> Seeing how hard it is to retrofit tests and docs to existing blocks,
> maybe we should require the following for any new non-scratchpad block:
> -samples
> -automated tests
> -documentation (in the block itself, I don't think our docs structure
> makes it easy to integrate docs from blocks)
What documentation format would be required here?
Does it make sense to use the Forrest format (how
would it be rendered)?
-- Andreas
> -a "community" (for example, at least three committers who need it)
>
> And require a vote before creating a new block, where the creator must
> provide evidence of the above.
>
> WDYT?
> -Bertrand
>
>
Re: Accepting new blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Jorg Heymans wrote:
>>
>> You're right, I'm also guilty of creating a few blocks without
>> formally asking.
>>
>> Seeing how hard it is to retrofit tests and docs to existing blocks,
>> maybe we should require the following for any new non-scratchpad block:
>> -samples
>> -automated tests
>> -documentation (in the block itself, I don't think our docs structure
>> makes it easy to integrate docs from blocks)
>> -a "community" (for example, at least three committers who need it)
>>
>> And require a vote before creating a new block, where the creator must
>> provide evidence of the above.
>>
>> WDYT?
>> -Bertrand
>
>
> I agree with this for core blocks.
>
> Will there be a different central repository then for the more exotic
> blocks that don't offer core functionality? Your community rule might
> hold people back from creating blocks for the fun of it.
> Example: i've been thinking about creating a text-to-speech block just
> for the learning experience. Unlikely that more than 3 committers need
> this, so where will it end up if i want to donate it?
>
> There was a discussion a few months ago about the need for a
> blocks.cocoondev.org alike site, maybe this is relevant again now? By
> default you would allow all blocks into an incubation phase and do a
> vote on the ones to absorb in the cocoon dist.
I think the community restriction for a block is too much when it's
created (alpha block), but they are ok for a supported one.
--
Stefano.
Text-to-speech (Re: Accepting new blocks)
Posted by Andreas Kuckartz <A....@ping.de>.
Jorg Heymans wrote:
> Example: i've been thinking about creating a text-to-speech block just
> for the learning experience. Unlikely that more than 3 committers need
> this, so where will it end up if i want to donate it?
I am no committer - but I might be interested in such a thing ;-)
Cheers,
Andreas
Re: Accepting new blocks
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.03.2004 12:28, Torsten Curdt wrote:
> 1) We more or less quietly dropped the scratchpad concept.
> Everyone prefers to create a block because it's more "pluggable".
>
> Maybe we should emphasize the scratchpad's existence a bit more
> again? ...or maybe have a block-scratchpad area instead of marking
> them unstable?
IMO it was a good move from old scratchpad to new scratchpad block as it
simplified the build handling, we could remove some special code for it
and so on. But how do you want to emphasize the scratchpad block's
existence? It's more a community thing and if we follow Bertrand's
proposal I guess we will get it better organized.
Joerg
Re: Accepting new blocks
Posted by Torsten Curdt <tc...@vafer.org>.
> Each block is more or a less a separate (sub) project. So there
> definitly needs to be a community around it before it should end
> up in our CVS. We failed at this point in the past. Take a
> look at some blocks we have, there are quiet a lot that don't
> have a community. So we should start considering this point
> with new contributions and I think Bertrands proposal is simple
> but good enough.
Hm.... I do see the problem that we get more and more unstable
blocks that might not have a community around them but...
...I guess that happens mainly because of two things
1) We more or less quietly dropped the scratchpad concept.
Everyone prefers to create a block because it's more "pluggable".
Maybe we should emphasize the scratchpad's existence a bit more
again? ...or maybe have a block-scratchpad area instead of marking
them unstable? ...maybe even on cocoondev.org as suggested?
...or maybe leave it like it is.
2) The still lacking "real blocks" (tm).
I guess with the current "blocks" it way harder to gather
a community around them when they are hosted somewhere else.
...just because you cannot try them out so easily then.
So basically the easiest/best solution might be...
Leave everthing like it is.
Ask yourself twice if the block really makes a valuable addition.
Ask the community if the donation of the block is being supported.
Help to get real pluggable blocks working in 2.2 :)
My 2 cents
--
Torsten
RE: Accepting new blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jorg Heymans wrote:
>
> I agree with this for core blocks.
>
> Will there be a different central repository then for the
> more exotic blocks that don't offer core functionality? Your
> community rule might hold people back from creating blocks
> for the fun of it.
> Example: i've been thinking about creating a text-to-speech
> block just for the learning experience. Unlikely that more
> than 3 committers need this, so where will it end up if i
> want to donate it?
>
> There was a discussion a few months ago about the need for a
> blocks.cocoondev.org alike site, maybe this is relevant again
> now? By default you would allow all blocks into an incubation
> phase and do a vote on the ones to absorb in the cocoon dist.
>
Each block is more or a less a separate (sub) project. So there
definitly needs to be a community around it before it should end
up in our CVS. We failed at this point in the past. Take a
look at some blocks we have, there are quiet a lot that don't
have a community. So we should start considering this point
with new contributions and I think Bertrands proposal is simple
but good enough.
Carsten
Re: Accepting new blocks
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi:
I think it is a good idea to talk about the "protocol to add new blocks",
but currently there is no an avalanche or an "invasion" of new blocks. :-(
As suggested the solution can be that every block can have his own
build.xml and just integrate it by extending a "main" build.xml. I am not
sure if this the old way. I also remember Stefano rewrote the build system
because it was too slow.
In fact, I am be glad to see Cocoon reaching new areas in form of optional
features called blocks.
Best Regards,
Antonio Gallardo.
Upayavira dijo:
> Carsten Ziegeler wrote:
>
>>Bertrand Delacretaz wrote:
>>
>>
>>>I don't think it would be very hard to make the blocks system
>>>more configurable, so that external blocks would need only an
>>>XML descriptor to be integrated at compile-time. But someone
>>>has to do it.
>>>
>>>
>>>
>>I always thought about simply adding all blocks that are in
>>the src/blocks/local directory (like we do with libs in
>>lib/local). But I don't know what effort this requires, but
>>it shouldn't be too hard.
>>
>>
> And use an Ant property to specify this location, so that you can point
> to blocks which are outside the Cocoon hierarchy.
>
> Upayavira
>
>
Re: Accepting new blocks
Posted by Upayavira <uv...@upaya.co.uk>.
Carsten Ziegeler wrote:
>Bertrand Delacretaz wrote:
>
>
>>I don't think it would be very hard to make the blocks system
>>more configurable, so that external blocks would need only an
>>XML descriptor to be integrated at compile-time. But someone
>>has to do it.
>>
>>
>>
>I always thought about simply adding all blocks that are in
>the src/blocks/local directory (like we do with libs in
>lib/local). But I don't know what effort this requires, but
>it shouldn't be too hard.
>
>
And use an Ant property to specify this location, so that you can point
to blocks which are outside the Cocoon hierarchy.
Upayavira
RE: Accepting new blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> I don't think it would be very hard to make the blocks system
> more configurable, so that external blocks would need only an
> XML descriptor to be integrated at compile-time. But someone
> has to do it.
>
I always thought about simply adding all blocks that are in
the src/blocks/local directory (like we do with libs in
lib/local). But I don't know what effort this requires, but
it shouldn't be too hard.
Carsten
Re: Accepting new blocks
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 1 mars 2004, à 10:43 Europe/Zurich, Jorg Heymans a écrit :
>
> ...There was a discussion a few months ago about the need for a
> blocks.cocoondev.org alike site, maybe this is relevant again now? By
> default you would allow all blocks into an incubation phase and do a
> vote on the ones to absorb in the cocoon dist.
I think what would help the most is an easy way to integrate "external
blocks" into Cocoon when building it.
If you look at the installation docs of the Fins block for example
(http://www.sidimar.ipzs.it/fins011/docs/install.html), this is way too
complicated. Nothing against Fins but it shows that integrating blocks
which are not in CVS is a currently..suboptimal.
I don't think it would be very hard to make the blocks system more
configurable, so that external blocks would need only an XML descriptor
to be integrated at compile-time. But someone has to do it.
Of course, Real Blocks will solve this but no one knows when.
-Bertrand
Re: Accepting new blocks
Posted by Jorg Heymans <jh...@domek.be>.
>
> You're right, I'm also guilty of creating a few blocks without formally
> asking.
>
> Seeing how hard it is to retrofit tests and docs to existing blocks,
> maybe we should require the following for any new non-scratchpad block:
> -samples
> -automated tests
> -documentation (in the block itself, I don't think our docs structure
> makes it easy to integrate docs from blocks)
> -a "community" (for example, at least three committers who need it)
>
> And require a vote before creating a new block, where the creator must
> provide evidence of the above.
>
> WDYT?
> -Bertrand
I agree with this for core blocks.
Will there be a different central repository then for the more exotic
blocks that don't offer core functionality? Your community rule might
hold people back from creating blocks for the fun of it.
Example: i've been thinking about creating a text-to-speech block just
for the learning experience. Unlikely that more than 3 committers need
this, so where will it end up if i want to donate it?
There was a discussion a few months ago about the need for a
blocks.cocoondev.org alike site, maybe this is relevant again now? By
default you would allow all blocks into an incubation phase and do a
vote on the ones to absorb in the cocoon dist.
Jorg
RE: Accepting new blocks (was:: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml DocumentHelper.java )
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> Seeing how hard it is to retrofit tests and docs to existing
> blocks, maybe we should require the following for any new
> non-scratchpad block:
> -samples
> -automated tests
> -documentation (in the block itself, I don't think our docs
> structure makes it easy to integrate docs from blocks) -a
> "community" (for example, at least three committers who need it)
>
> And require a vote before creating a new block, where the
> creator must provide evidence of the above.
>
> WDYT?
+5
Carsten
Accepting new blocks (was:: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml DocumentHelper.java )
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Dimanche, 29 fév 2004, à 18:53 Europe/Zurich, Carsten Ziegeler a
écrit :
> As far as I know (from my weak memory :) ) there hasn't been a vote
> at Cocoon about "accepting" this block...
Sorry, last I told the lenya-dev guys that IMO a vote was not needed to
create a new block in Cocoon (but I also said that it would be polite
to ask ;-)
> ...I'm really worried that everyone starts a new block whenever he
> thinks it's right to do without asking anyone (This is not targetted
> at you Gregor.). I did this myself, yes.
> But I think we should sometime really start to discuss new blocks,
> otherwise we get burried under too many blocks noone maintains.
> In fact a block is a new subproject that perhaps should go through
> incubation etc...
You're right, I'm also guilty of creating a few blocks without formally
asking.
Seeing how hard it is to retrofit tests and docs to existing blocks,
maybe we should require the following for any new non-scratchpad block:
-samples
-automated tests
-documentation (in the block itself, I don't think our docs structure
makes it easy to integrate docs from blocks)
-a "community" (for example, at least three committers who need it)
And require a vote before creating a new block, where the creator must
provide evidence of the above.
WDYT?
-Bertrand