Re: scope creep in DDP Policy
Osamu Aoki <osamu@debian.org> writes:
> After thinking again about the state of DDP policy, I had to agree with
> Adam that we need to narrow our scope of this proposal now before going
> even to step (1) above.
Excellent, I'm glad to hear that.
> In order to narrow scope of discussion, we should separate general
> policy issues related to generic documents which comes with packages
> and their manual pages and info pages. Let's keep them separate.
>
> DDP policy should be policy on the document specifically written for
> "Debian" as discussed in Chapter 3.
>
> It should define,
> 1] Accepted copyright types (GPL, GFDL w/o invariant)
> 2] Recommended copyright (GPL or GFDL w/o invariant, need to decide)
> (I am GPL proponent)
> 3] Accepted source formats (debiandoc-sgml, docbook-sgml, docbook-xml,
> ...)
> 4] Recommended source format (docbook-xml)
> 5] Minimum publish format (html/multi-page, txt/single file)
> 6] Recommended publish format (above plus PS and PDF)
> 7] State SGML source not to be included in binary
> 8] Formalize use of document install directory as package
> /usr/share/doc/Debian/refarence-name/*.LANG.FORMAT
> or
> /usr/share/doc/Debian/FULL-LOCALE/*.txt etc.
> 9] Formalize use of document install directory as web page
> 10] Formalize use of standard document directory as source ("should")
> 11] Formalize CD document directory tree (if it can be included here.)
>
> 8]-11] needs some good review.
I agree in principle, although I'm have a disagreement in substance
regarding use of /usr/share/doc/Debian. This probably isn't the place
for hashing out the substance though, we're talking scope. But you do
bring this up later, so more below.
> First discussion point before going to the step (1) is narrow the scope.
> Let's focus on Chapter 2 and Chapter 3. Can we agree?
Um, why start there? Right in 1.1, Scope, we read "all your
documents belong to us". We need to get the new, restricted scope
down in the policy under section 1.1.
I can just start revising that -- but I don't want to step on any
toes. I guess I should wait a bit to see if we have consensus.
Review of Chapter 2 tells me it's ok as is I think. Could use a
little rewriting for smoothness.
> Let's us think again the question of "directory structure". I do not
> think we had any major discrepancy between us on other issues.
>
> Should we conclude here on "directory structure" or ask opinion from step
> (1)?
Personally I think in view of our revised ideas about our scope, the
idea of /usr/share/doc/Debian becomes a little dubious. Not all
Debian documents are covered by the DDP policy.
I guess this raises a point. If the scope of the DDP Policy is DDP
documents, there might be items in there that we wish to raise to the
level of Debian Policy of Developer's Reference materials (general
Debian documentation best practices, not just applying to DDP).
I'm happy to incorporate things like this in the Developer's
Reference, although I'd like to review the discussions on
/usr/share/doc/Debian. We might even be able to share text between
the two documents (using CVS and shared included modules).
On /usr/share/doc/Debian/, I'm not sure if it's really necessary,
since collection of Debian documentation is already done in a single
section in the doc-base registration and things of that nature.
Again, pointers to discussion on this list or elsewhere would be
appreciated.
> PS: Since Adam retracted source only distribution model, last part of
> 3.5.2 can be removed, I think.
Yes. I think all of 3.5.2 should mention package names and not the
*.deb names. We also need to make a call on the issue of:
developers-reference-en
developers-reference-fr
Or, alternatively:
developers-reference
developers-reference-fr
This is of particular interest to me since I've just finished the work
on splitting developers-reference into language-specific docs.
Note that this stuff is also potentially a policy/best practices
candidate too.
If you don't mind some radical surgery, I might be able to go through
the document, trimming the scope, and marking sections which should be
destined for policy or best practices as appropriate.
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
Reply to: