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:44:01 GMT

On Sunday, Sep 21, 2003, at 01:40 Europe/Rome, Joerg Heinicke wrote:

> Stefano Mazzocchi wrote:
>>> OTOH if it is the case, then we're back to needing an uninhibited 
>>> way to experiment with them, and the block.xml and the whole block 
>>> content may need to be duplicated in 2.2 until cocoon-blocks is 
>>> worked out.
>> yes. if the fop block, for example, requires dependencies on batik, 
>> it cannot behave the same as a fake block and a real one. it has to 
>> move.
>>> But if we agree that any blocks in 2.2 will be kicked out later 
>>> either to find a home at cocoon-blocks or elsewhere our hands still 
>>> will be free.
>> Yes, I think this is a good compromise:
>> 1) keep blocks that don't have subdependencies on cocoon-2.1
>> 2) move blocks that have dependencies in cocoon-2.2
>> 3) when the block architecture is finished, design the procedures on 
>> how blocks are
>>  - submitted
>>  - accepted
>>  - developped
>>  - released
>>  - frozen
>> i expect this to be a can of community worms and personal interests, 
>> so i don't want to tacle this until we have something that works in 
>> place.
> 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. Is the above proposal 
> only because of community issues? What prevents us from doing the move 
> to cocoon-blocks as first step?

First of all, because I'm not sure if one CVS module for blocks is a 
good thing to do.

For example, you can't tag parts of a module.

But also, asking a new CVS module to be created for every cocoon block 
seems a little bit excessive.

Besides, what happens if blocks evolve in a back-incompatible way and 
require two branches? do we branch the entire module? do we move the 
block in its own module?

If cocoon ends up having 230 different CVS modules, the ASF 
infrastructure will start streaming and the board will fear that cocoon 
is exploding.

These are only a few of the reasons why I want to be very cautious with 
this block move: when the block implementation is finished, I fear 

before everybody and their sisters start to branch off their single 
stylesheets into a different block, we need at least a few rough 
policies in place. keeping them in cocoon-2.1 will, at least, force 
people to think twice before adding and moving things around.

Blocks will unleash the power of an incredibly scalable parallel 
development. Given the amount of activity this community has, I'm more 
concerned on how to avoid it gains too much speed before it can be 
safely slowed down and guided thru useful directions.


View raw message