[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cvs commit: distrib/cvsup/sup README distrib/cvsup/sup/doc-all releases list.cvs.en distrib/cvsup/sup/www releases list.cvs.en list.cvs.text
- To: obrien@xxxxxxxx
- Subject: Re: cvs commit: distrib/cvsup/sup README distrib/cvsup/sup/doc-all releases list.cvs.en distrib/cvsup/sup/www releases list.cvs.en list.cvs.text
- From: John Polstra <jdp@xxxxxxxxxxx>
- Date: Thu, 02 Apr 1998 05:23:27 -0800
- Cc: cvs-committers@xxxxxxxxxxx, cvs-all@xxxxxxxxxxx, cvs-distrib@xxxxxxxxxxx
- In-reply-to: Your message of "Tue, 31 Mar 1998 19:39:16 PST." <19980331193916.63457@xxxxxxxx>
- Sender: owner-cvs-distrib@xxxxxxxxxxx
> > stuff either. Again, these files are easy for clients to block
> > in their "refuse" files.
> But we do have say "ports-lang" in addition to "ports-all". This
> could also be added to the refuse file.
> Thus can "doc-all" also be offered in its componates? These being
> doc-handbook, doc-faq, doc-ja?
I don't object in principle. We'd need "doc-base" too, to pick up
the Makefile. I also have been persuaded that subcollections to
separate out the language-specific parts (e.g., Japanese versions)
are becoming more important all the time. I just want a chance to
organize it in a way that will be consistent across the board, and
that scales reasonably well. Once a collection exists, it's virtually
impossible to eliminate it or to reshuffle its contents without
causing disruption (mass file deletions) for users. In particular,
there's no painless way to migrate a set of files from one collection
into another one. So it pays to get it right the first time.
Taking care of this is on my white board, and if you'll bear with me a
little bit longer, I'll get it done.
John Polstra jdp@xxxxxxxxxxx
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-knowledge is always bad news." -- John Barth