cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: on better release and version management
Date Mon, 22 Sep 2003 21:36:26 GMT
Stefano Mazzocchi 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.
> 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.

So it's a community issue on the one hand and a "we do not know which 
problems could be arise" on the other hand. The first thing we can of 
course handle now, the other thing we will see ...


View raw message