cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <jheini...@virbus.de>
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 ...

Joerg


Mime
View raw message