cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Block Management [was Re: on better release and version management]
Date Thu, 25 Sep 2003 10:45:50 GMT

On Thursday, Sep 25, 2003, at 08:51 Europe/Rome, Bertrand Delacretaz 

> Le Mercredi, 24 sep 2003, à 23:08 Europe/Zurich, Stefano Mazzocchi a 
> écrit :
>> On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson 
>> wrote:
> <lots-of-snips cause="agree"/>
>> The above suggests one simple, but really important thing:
>> the block 'health' metadata should *NOT* be included in the block, 
>> but should be looked up from a centralized 'weather reporter' part of 
>> the block librarian.
> Yes - and maybe we shouldn't impose too much structure on this weather 
> report, just require that block providers have one "block status" 
> documentation page, where they tell people about contract stability, 
> API stability, future plans, active contributors and the like.

Yeah, that might do the job.

> If this is somewhat narrative rather than checkboxes, users should be 
> able to get a feel of how seriously the block authors take their work, 
> and not finding the expected info will be a sufficiently bad sign.

Very true.

>> ...The best way to judge is to make a vote.
>> And the vote should not, in any circumstance, make the block being 
>> voted bad if the vote doesn't pass.
>> So, the answer to
>>  3) is the community healthy?
>> is misposed. I would like to have somethign a little less judging: 
>> something like
>>  3) is the cocoon community officially supporting this block?
> Agreed.
>> The risk is to come up with something which is not really meaningful. 
>> Because "official support" doesn't really mean anything.
> Agreed as well. I still like "supported", meaning that the community 
> cares for a particular component.
> Many projects use also "contributed" to mean that a piece of software 
> is distributed along with the main code but comes from outside.
> How about "supported", "contributed", "experimental" and "deprecated" 
> blocks?

I think that "contributed" and "experimental" are somewhat orthogonal, 
in fact, linotype can be considered both contributed and experimental.

"experimental" judges the technical concepts included in the block. We 
should, following the years-old Apache spirit, that we made judgement 
on community health and let users judge technological merits.

[also, developers tend to be more rational about sociology evaluation 
than they are about technology evaluation, because they care more about 
the second, normally]


  contributed -> no broad community support

  supported -> broad community support

  deprecated -> community either moved onto something else or dropped 
the concept alltogether.

NOTE: a contributed block might find itself deprecated without never 
being supported. This is the full state/transition diagram:

              v                                            |
-(birth)-> [contributed] ----------(death)---------> [deprecated]
              |                                            ^
              +--(maturity)-> [supported] --(retirement)---+

the transitions that require community vote (majority) are:

  - maturity
  - retirement

the other transitions can be done by every committer in every project 
under control of the cocoon PMC and require only a "proposal" to be 
discussed on the cocono development mail list.



View raw message