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
