cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Supported and unsupported blocks
Date Wed, 16 Mar 2005 23:40:41 GMT
David Crossley wrote:
> Jeremy Quinn wrote:
>>Don't get me wrong, I am happy you are being pro-active about this.
>>However, I see several items on the "unsupported" list which are IMHO 
>>important components of Cocoon, or are blocks that I use regularly in 
>>my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and 
>>others). In most cases, the fact that they do not currently have >2 
>>supporters does not effect their quality and usefulness.
>>On reviewing this list again, I see several blocks that I have worked 
>>on that I probably should have put my name to, and I notice several 
>>blocks that I know people actively care about, that they have not put 
>>their name to.
>>Maybe I misunderstand the purpose of having "supported" and 
>>"unsupported" blocks, but I would hate to useful work being sidelined 
>>by not attracting usage or new contributions.
> Thanks for raising these issues. I wrote a similar mail but didn't
> yet send it ...
> I am concerned about the signals that this classification,
> and listing of committers, sends for community-building.
> Here are some random thoughts - sorry no time ...
> Some blocks have no committers listed, e.g. midi, asciiart
> However, they probably don't need much maintenance, so why would
> they be listed as unsupported, or worse, moved offsite because it
> appears that no-one cares.
> I am not putting my name against any blocks, but that doesn't mean
> that i won't help with them. Whenever i make some spare time
> to attend to Bugzilla, i will work on patches for any block.
> We try not to mention specific committers names. In fact, we voted
> a while ago to remove author tags from code (but not yet done).
> We really don't want to encourage the community to contact individuals.

Whenever I work as trainer or consultant and Cocoon is the subject, people 
always ask me the same questions about maturity and community of Cocoon and its 
blocks. We should tell our users clearly what *we* consider as "supported", 
"deprecated" and "committed" and then everybody can decide himself what he does 
with this information.

The wiki page is only an indicator which should help us to decide to get an 
answer on the community aspect which is one part of the answer which state a 
block has (the others are interface stability, implementation stability and 
available automated tests).

Additionally I like Bertrands idea of a more verbose description of a block 
status, that could be part of every block documentation (see for details).

Reinhard Pötz           Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message