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
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
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
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
sur
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
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 th
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
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 integrat
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
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 abso
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 thinkin
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 thin
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 t
13 matches
Mail list logo
