cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: on better release and version management
Date Sun, 21 Sep 2003 13:57:43 GMT

On Sunday, Sep 21, 2003, at 12:39 Europe/Rome, Upayavira wrote:

> Steven Noels wrote:
>> Joerg Heinicke wrote:
>>> IMO this is difficult to maintain. If someone wants to look on the 
>>> code base of a block he has to search for its dependencies first or 
>>> search for the code at different places. Can't we extract the blocks 
>>> from 2.1 "as they are" at the moment and move them to cocoon-blocks 
>>> module, so that they are collected at one place.
>> I like this: +1
> +1 I like this too. Minimal changes to 2.1 to make it work with the 
> new blocks repository, and we can then get on with 2.2 core.

to be clear: I'm not against this, but only after people realize the 
problems that might come up and we come up with consensus on how we are 
going to deal with those problems *when* they come up

Not if, because you can bet that over-blockization is going to 
happen... or, at least, asked for.

As it is today, blocks are not only modular packages to extend cocoon 
(as fop and batik, for example, who triggered the creation of the fake 
block system), but also a way to propose new stuff as one-man-shows.

I fear one-man-shows.

At the same time, we need 'sort-of incubation' practices for blocks, as 
it is impractical to think that a cocoon committer would develop 
his/her code outside and submit it only when there is a community 
around a block.

the block system will work effectively *ONLY* if there is strong 
cross-pollination between blocks and if the cocoon community keeps 
strong oversight over what happens.

this hasn't been so for many blocks so far and I see this as a 
potential problem.


View raw message