cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: on better release and version management
Date Tue, 23 Sep 2003 06:38:55 GMT
Stefano Mazzocchi wrote:
> 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.

May I guess where this fear comes from... Avalon? ;-)

I have the same fear.

> 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.

Yes, I agree.

This is why I had proposed to keep scratchpad blocks in the scratchpad 
and not mix them with released ones. This makes one-man shows easier to 
do and more difficult to manage.

> 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.

It's just the beginning.
I would suggest to:

1) keep the voting system and responsibility over blocks as now, that is
    open to all Cocoon committers
2) make a scratchpad-incubaton-callitwhatyouwant directory or even
    better CVS module where alpha blocks or features are done
3) partition commit acces like this:
    1) only core cocoon committers can commit to the core
    2) all committers have access to Lenya, Forrest and Blocks
       (when/is Forrest going to actually move?)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message