Re: Debian Documentation Hierarchy
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> On Mon, Apr 27, 1998 at 03:44:33AM -0400, Adam P. Harris wrote:
> > Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> > > This is the reason why I want total control over sections. I think
> > > letting document registrations create sections will lead to
> > > sloppyness and inconsistency in the long run. If no section is
> > > appropriate, it should be created with the structure of the whole
> > > DDH in mind, which would be my task. It would also allow to move or
> > > duplicate some related documents.
> >
> > While I definately sympathize with your concern here, I feel that the
> > best solution would be to *codify* sectional units, while still
> > allowing the creation of subdirs within sectional units. To my mind,
> > the issue of whether it may make sense to place a bunch of
> > app-specific documents in a subdir is an issue which is akin to what
> > we do in /etc, and should be placed under the control of the package
> > maintainer.
>
> I'm not sure if I agree or not. However, this is what Marco and me worked
> out (coming from totally? different positions):
>
> A package may create subsections, but the subsection becomes a part of the
> DDH when multiple packages (two or more) want to use the same (or a very
> similar) subsection.
>
> For the benefit of the user and for the functionality of the over-all design
> of the DDH, it is essential that the documents are splitted among the DDH in
> the defined way --- user manuals below user, development documents below
> devel and so on. Just dropping all sort of documents in a single (created)
> section is quite confusing, IMHO. Personally, I consider a wrong placed document
> as a bug.
>
> This is a bit different from /etc, because the user wants to find the
> documentation in the appropriate section. The situation is more akin to
> /usr/share, /usr/ and /, opposite to using just a /opt directory.
>
> Most likely this is not at all what you meant, but I thought I would spell
> it out, to make my intentions clear.
>
> As long as the purpose of DDH defined sections is clear, and only a single
> package uses one or more subsections in the appropriate locations, all is
> fine.
Actually, it sounds like we agree. I would like to differentiate
sematically (with the terms 'app-subsection' vs. 'subsections' per
se). I don't know if you want to adopt my terminology or not; I feel
having separate terminology makes the distinction clearer. If so, you
could say, "it is permissable to create app-subsections, but not
standard subsections". Perhaps better terms could be found.
> > Marcus, this is the std way we do collaborative packages (i.e., dpkg,
> > deity). Do you know CVS? Does this sound good?
>
> This sounds very good. I know what CVS is, but I need to learn the technical
> details (I didn't have write access to one before). However, this should be
> no problem. I have no problems with you acting as a release manager.
Ok. 'cvs update', 'cvs add', and 'cvs commit' are really the only
commands you should need. 'cvs diff' is very useful too... ;)
> > Actually, I wouldn't mind having an "understudy release manager"
> > uncase something goes dreadfully wrong and I'm not available. I think
> > a central repository would be good. Of course I would retain ultimate
> > responsibility for the quality of the release.
>
> We already have the non-maintainer-release procedure for crisis, let's not
> make things more complicated than they are.
Ok...
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: