[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CVS location for dselect documentation for beginners



On Sat, Dec 07, 2002 at 04:02:18PM -0600, Adam DiCarlo wrote:
> > The dselect beginners guide is the one document in the b-f CVS tree that
> > _really_ doesn't belong there: if you remove the dependencies on the b-f
> > files from the header, you'll notice just a few missing tags, none of which
> > are even borderline important to the document itself, and all of them
> > trivial to arrange in a separate tree.
> 
> I agree completely.  I wondering though if this should go in the DDP
> CVS area, or even perhaps in the dselect package.

If it goes in with dpkg, then we have a whole new set of arrangements to
make with the dpkg developers in order to accept the document, to have
others work on it, translate it, etc. I'd very much like to avoid that.

> If in the DDP CVS area, should it be packaged as well?  I think it will
> need to be...

It can be packaged from there too, I don't see how that would necessarily
impede the packaging process.

> > I'm thinking of moving it out into the DDP tree where it will likely get
> > some more attention and tender loving care ;) Any suggestions for preserving
> > the history? cp the ,v files, or just ignore that and cvs remove here + cvs
> > add there, with a pointer to the old place just in case anyone cares?
> 
> I would suggest doing a checkout from the head, then copy those files
> over and do a CVS import from that, then start adapting it for being
> stand-alone.

Right, so losing the history? Or does cvs import do something special to
preserve history?

> > The situation is similar with the release notes, which just need a few
> > tags to be able to skip some info for architectures recently released.
> 
> Yes, ditto.

The FAQ needs a similar set of information so we could even keep this in the
parent directory of the manuals tree and share it.

> > The installation manual needs entities from the po files of debootstrap,
> > but the document will likely need a rewrite for debian-installer, and
> > I'm not so sure if it will be doable in exactly the same way with d-i.
> > In any case, we can write scripts to obtain the data from wherever it
> > is.
> 
> Yup.  I already have some code that uses apt-get to download pkgs it
> needs (e.g., ASCII version of relevant man pages).

Oh, great.

The set of makefiles would also be much simpler if it the installation
manual was standalone and worked with the variables from its own files
instead of working with other files like it does now. Given the past
recurring headaches we had with the build system, this is a big bonus :)

> Is anyone responsible for the rewrite of the install manual for d-i?
> I'd prefer not to take it since I'd like to put my attention on
> developers-reference, doc-base, and my bugs for a while...

Chris Tillman did the large amounts of work on the current install manual,
IIRC, he might be interested in this.

-- 
     2. That which causes joy or happiness.



Reply to: