cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: [RT] Rules for adding blocks and functionality?
Date Sun, 23 Oct 2005 20:25:31 GMT
Ralph Goers wrote:
> 
> 
> Andrew Savory wrote:
> 
>>
>>> * We really need to get rid of obsolete stuff. Must really every 
>>> single block go to 2.2? Are there some oneman shows that better 
>>> could be returned to their creator and driven on source forge or 
>>> Cocoon-dev?
>>
>>
>>
>> Hmm. I'm not convinced of this. The problem is that we can't 
>> anticipate which blocks our users want, they may have perfectly valid 
>> reasons for using e.g. the SQL Transformer (even if we wished they 
>> didn't). I don't know how we can remove historical functionality 
>> without upsetting -someone-. I'm not sure how this can be solved ...
> 
> 
> I see two sides to this.
> 1. With binary builds where blocks are separately and transparently
> downloaded getting rid of old stuff can be seen as much less of an issue.
> 2. Having old stuff around leaves lots of ways to do things which adds
> to the confusion and reluctance to use Cocoon because of the learning
> curve.  Good documentation with recommeded ways of doing things could
> help to solve that.

Basically, we relegate blocks not by removing or reducing them, but my
lifting others. We will have a background of many blocks, many one man
shows, half maintained ones, etc. However, we will also have lists
saying "these are the cool ones, the ones that really work and are
really useful". Given that the cruft isn't in that list, the cruft has
already been relegated, but hasn't been removed for those that depend
upon it.

Regards, Upayavira

Mime
View raw message