cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Supported and unsupported blocks
Date Tue, 15 Mar 2005 09:14:58 GMT
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> <snip/>
>> So far, I've moved all blocks from /trunk/src/blocks to 
>> /blocks/[status]/[name]/trunk and updated the svn:external property on 
>> /trunk/src/blocks to "re-import" them at their former place. This way 
>> everything should work as it did before the change. 
> Cool! As I promised before you get my hero plate and a beer at the next 
> GT for daring to move out the blocks from trunk.
>> As Daniel and Antonio have already found out, at 
>> I set up a page that 
>> should give us an overview on who is able to support which blocks. 
>> This should help us to decide on the status we want to give every block.
> And extra points for putting about everything under blocks/unsupported 
> in SVN. That should give us a well needed kick in the ass for actually 
> deciding what Cocoon is.

let's look at the results:

I'd say the following blocks are "supported"

authentication-fw	AG,CZ, 	
batik	CZ, VG, SW	
cron	RP, CZ, VG, SW, LG	
databases	AG, DF, SW, LG	
deli	AG, 	
fop	AG, CZ, VG, BRD, BD 	
forms	RP, AG, DF,CZ, VG, SW, BRD, BD, LG 	
hsqldb	RP, VG, 	
html	UV, VG, SW, BD	
lucene	JQ, VG, SW	
ojb	AG, JQ, VG, BD
poi	AG, BRD 		
paranoid	RP, SW	
portal	CZ, 	
profiler	CZ, VG, BRD 	
qdox	AG,BD
session-fw	AG,CZ 	
template	DF, BRD, LG 	
xsp	AG, VG, SW

These blocks have at least two committers that support them. I added "portal" as 
I know that there are many users out there (regular bug fixes via bugzilla) and 
Ralph hasn't added his name for some reason (although he works regualarly on 
fixing bugs and applying patches.)

I also added Deli as Antonio and Marc are both working on it and I therefore 
don't consider it as one-man-show.

                                   - o -

The following blocks either have only one committer who supports them or they 
aren't supported by an active committer at all.

apples	BRD 	
bsf	AG, 	
eventcache	GH 	
faces	VG, 	
jfor	BD 	
jms	GH 	
linkrewriter	VG, 	
mail	VG, 	
proxy	BD 	
querybean	JQ, 	
slop	BD 	
stx	DF, 	
taglib	VG, 	
tour	BD 	
xmldb	VG, 	

Where shall we draw the line between "supported" and "unsupported"? Is it really 
the "two committers rule" that I applied above?

Another thought: maybe we should add another "state" called "sample". "tour" and 
"petstore" could be "sample" blocks,  as well as a future block that contains 
all samples.


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

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


View raw message