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 Tue, 23 Sep 2003 12:15:28 GMT

On Tuesday, Sep 23, 2003, at 08:38 Europe/Rome, Nicola Ken Barozzi 

> Stefano Mazzocchi wrote:
>> 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.


At the same time, I want to avoid the "move things around" dance that 
happens when something 'matures'.

As 'maturity' is not a black/white process (there is no point in time 
where a community turns into maturity, it's just a feeling)

Instead of associating 'maturity levels' to the actual location of a 
block, I would state that as a 'label' attached to it, a label that the 
block deployer reacts to and prompt the user for action in case the 
block is not considered "final" by the community.

That would:

  1) keep the freedom to initiate as many blocks developers want
  2) avoid the 'move things around' CVS dance
  3) allow easy and mechanizable checking of which blocks are considered 
"stamped" by the cocoon community.

so, the only thing left is to define how you get those blocks 
"stamped", but I think it would just require a community vote with a 

Such "stamping" should be done thru the use of a digital certificate so 
that the block deployer can say "this is a block certified by the 
cocoon community as final".

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

+1, I would just suggest, for 2.2, that all blocks that want 
"certification" are required to obtain this thru a vote. And, before 
the certification can happen, a few things must be done, mostly, 
community diversity checking and documentation availability.

> 2) make a scratchpad-incubaton-callitwhatyouwant directory or even
>    better CVS module where alpha blocks or features are done

-1 on this, as for the cvs-dance argument above.

> 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?)

don't know the status of this


View raw message