Marcus Brinkmann <[EMAIL PROTECTED]> writes: > On Mon, Apr 27, 1998 at 03:44:33AM -0400, Adam P. Harris wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
