Re: CVS location for dselect documentation for beginners
Josip Rodin <joy@gkvk.hr> writes:
> 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.
Well, it's actually far less work for the DDP since it takes the
burden off us to maintain it. I would think it just depends on
whether these guys want to maintain it (which I would doubt) and if
so, it is probalby pretty much up to them to accept the documents and
work with contributors.
> > 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.
No, it's just more work to be done is all....
> > > 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?
No, you would lose the history. But so what? Or rather, if you
wanted the history, you'd go to the boot-floppies package. Why have
the history in two places, eh?
If you really want to duplicate the old history over to the new
location, yes, you would have to copy over the ,v files.
> > > 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.
That is going to get a bit tricky if you are providing these as source
packages.
What I would suggest doing as an alternative is to create a
'common-deb-data' CVS module, and via the CVS modules functionality,
including this module with the various CVS modules that use it, e.g.,
the FAQ etc. This would effectively do:
CVS checked out appearance Repository location
-------------------------- ---------------------------------
faq/ -> ddp/manuals.sgml/faq
faq/common-deb-data/ -> ddp/manuals.sgml/common-deb-data
install/ -> ddp/manuals.sgml/install
install/common-deb-data/ -> ddp/manuals.sgml/common-deb-data
...
> 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 :)
I completely agree. The old system is rather overcomplex as well.
In fact, there are even deeper issues. Are we happy with the way
we're using SGML conditional inclusion for porter stuff? Aren't we
rather annoyed with the difficulty in validating that and the
complexity it presents to authors? Should we move to another means of
marking up arch-specific sections? If we were using DocBook, we could
use (pretty naturally) the 'arch' attribute on <para>, <phrase>, and
<section>, and then handle the presentation issues (should we have one
manual with arch-specific stuff simply styled/presented in a certain
way? or one manual per arch as we have now?) in stylesheets.
> > 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.
I hope so. He's done good work.
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
Reply to: