Accepting new blocks (was:: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml DocumentHelper.java )

[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

Re: Accepting new blocks

[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

[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

[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)

[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

[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

[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

[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

[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

[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

[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

[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

[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 )

[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