You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jorg Heymans <jh...@domek.be> on 2004/03/01 10:43:01 UTC
Re: Accepting new blocks
>
> 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
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