cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: Supported and unsupported blocks
Date Wed, 16 Mar 2005 14:59:46 GMT
On Wed, Mar 16, 2005 at 09:41:37AM -0500, Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
> >IMO it is an esential service for our users that we in a honest and 
> >realistic way tell what we actually, in practicem, with real work, 
> >support rather than what we whish we supported.
> 
> And I think nobody disagrees with that. Status page (suggested somewhere up 
> the thread) indicating the status of the block, some additional information 
> about the block, etc, will accomplish this even with flat directory 
> structure in SVN.
> 
> What exactly changing directory structure buys you? If there is clear and 
> structured documentation about the blocks (it can use structure like 
> supported/unsupported/contributed/abandoned/whatever) and similarly 
> structured hierarchy in the sample webapp, what, on top of this, directory 
> structure in SVN gives?
> 
> I'm not so against moving stuff, but I'm just trying to understand why to 
> move.

I can live with dividing blocks up into directories and moving blocks
around occasionally if that is what we decide, but I have a hard time
understanding the reason for doing this, unless...
...are we dividing into separate directories so we can have separate
downloads, e.g. cocoon-core.tgz, cocoon-extras.tgz, etc.?  If so,
then perhaps the distinction should be made by what is commonly used
together, rather than by how supported, tested, etc. the components
are (with an exception for truly experimental, not really released code.)
Otherwise we are just creating more decisions to make when developing
and downloading while not saving ourselves or our users any bandwidth.

I think it is very important to create the types of distinctions between
blocks which we are talking about (level of support, liveliness of
development, degree of test coverage, etc.)  I just don't see the
benefit of doing this via division into directories.  Directories only
allow for one dimension of grouping, and as we already see we have
several orthogonal concerns along which there is a tension to create
a clear categorization.  Meta-data used to generate separate
documentation listings seems ideal for this usecase.

--Tim Larson

Mime
View raw message