Gervase Markham wrote:
>
> > > is designed for this sort of thing. My objection was to [her] justification
>
> Oops, sorry :-)
It's okay. ^^
> > > 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.
Release docs in one directory, everything else in another.
This is confusing?
> Also, if "software" is for releases, why not call it "releases". The name
> is very counter-intuitive.
done (since two nights ago, actually)
>
> > /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?
- They are aimed at different audiences.
- Their purposes are completely different.
- They don't follow the same time-table.
- Releases don't always correspond with major changes in code that
require documentation changes or additions; they come out after
many minor changes, also.
- Major changes to the code don't immediately trigger new releases;
the code must be tested and stabilized first.
- Software-that's-released is static. Software-in-development is dynamic.
As I see it, if you were to create a table of all the project-related docs,
you would get something like this:
|| Development Docs || Use Docs (not "User") |
||overview|documentation|project-org||overview|relnotes|build-instruc|
-------||----------------------------------||-------------------------------|-
project||what is |how does it |community/ ||what's |(self- |how to get it|
name || it? | work? |involvment || it do? |explain)| |
You want the split along each row, then by columns
I want it along the column groups, then by rows, then by columns.
> 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.
I don't know how module owners are set up for the site. Does adding a
release to the list generally involve checking out the entirety of the
project documentation? Should it?
Anyhow, for comparison, I have put up what, as far as I can tell from
these posts, you want for the directory structure:
http://fantasai.tripod.com/Mozilla/2000/reorg-new.txt
- no releases/ top-level directory - there's one under each project
- no tools/ directory
Find where the following documents would fit, and notify me of any
changes necessary:
http://www.mozilla.org/bugs/
http://www.mozilla.org/quality/help/bugzilla-helper.html
http://www.mozilla.org/bonsai.html
http://www.mozilla.org/newlayout/
Get someone to second that redesign, and if no one counters with a stay,
I'll replace reorg.txt with it. (I'll still dispute the exclusion of /tools)
