> > is designed for this sort of thing. My objection was to [her] justification
Oops, sorry :-)
> > for the existence of the /software directory (see the comments at the
> > bottom of the file).
>
> No, no. /projects is designed to hold the sort of information needed by a
> developer to _understand and modify the code_. /software is for the release
> of the software. Libraries are software, are they not?
This means that any bit of software capable of being released on its own
will need a directory under "software" and one under "projects" as well.
This seems to me like a recipe for confusion. Also, if "software" is for
releases, why not call it "releases". The name is very counter-intuitive.
> > > Having a /projects hierarchy makes about as much sense as having a /docs
> > > hierarchy. Given enough mindless advocacy, anything could be considered
> > > a `project'.
> >
> > Again, true.
>
> That's the point. Then every initiative (since you don't like the word
> project) can have a directory to arrange and display their files.
I have no problem with the word project, not the idea of a projects
directory - it was in my proposal, after all.
> > I'm now leaning more towards having a single top-level directory for each
> > "project". But then we need to decide what additional top-level
> > directories we need for information which applies to the whole
> > organisation (such as hacking docs etc.)
>
> You'll wind up with more top-level directories than you can count,
> and a poor organization to go with it.
Multiple top-level directories isn't necessarily a bad thing. Any system
will work poorly if people don't understand it, and well if they do.
> /softWARE - holds everything relating to the distribution of
> mozilla.org's _wares_
>
> Software is not a project. Development of software is a project. The
> end result of the /project/ is a released /product/. The product is
> software, not the project.
Then, I think this directory has the wrong name, and should be called
"releases".
But why do you think the distinction between software-in-development and
software-that's-released is so big as to split the two parts apart? Why
can't they live together? It also makes it much harder for each software
module owner to have a CVS checkout of just his stuff, because it's across
multiple disparate directories.
> Word games aside, I think there's a valid distinction between using
> the software--for whatever purpose, be it end user or middleman--and
> the development of the software. There is no reason for users to sift
> through project docs aimed at developers.
Having them stored in the same directory does not mean that this will be
the case - this is down to what's on the web pages, not where they are
kept.
> Remember, _HyperText_ Markup Language /can/ link across directories.
Yes, but CVS isn't very good with it. And people inserting stuff will be
mentally confused about where things should live.
Gerv
