cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: Block Management [was Re: on better release and version management]
Date Thu, 25 Sep 2003 06:51:29 GMT
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.

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.

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


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

Here are some suggested examples with blocks that I know (more or less) 

Considered part of the "mainstream use" of Cocoon and supported as 
such, documented, tested before each release: axis, batik, chaperon, 
cron, databases, fop, hsqldb, html, itext, jfor, lucene, mail, portal, 
velocity, woody

Either one-man shows, outside contributions with no broad community 
support or samples with no additional functionality: deli, midi, qdox, 
linotype, petstore

Either wild experiments, or use experimental technologies, or waiting 
for feedback: slop,stx,eventcache,scratchpad,asciiart

Not recommended for new projects, support will likely go away: xmlform

Please don't flame on particular classifications at this point, I'm 
just trying to get the idea across ;-)


View raw message