On Thu, May 02, 2002 at 01:44:50AM -0500, Manoj Srivastava wrote:
> Anthony> Policy at the moment provides a fairly thorough grounding in
> Anthony> Debian's best practices. That's highly useful.
>
> Thorough is a matter of opinion. I think it is inconsistent,
> bumbling mess, occasionally wrong, and bloated, it occasionally
> contradicts itself, related issues are often scattered throughout the
> document, it does not have enough rationale. Its coverage of best
> practices is patchy, and what there is adds to the problem
> determining what is policy and what is the document merely being
> chatty.
I totally agree with Manoj here.
I think that before anyone sits down a rewrites the policy document
(which we really need to do!), we should agree on a sensible structure
that is likely to work. Doing too much detailed writing at this stage
seems a little pointless.
Here is a very brief attempt at a draft structure, which will
certainly need improving, but gives an idea of what I mean:
Part I: The Debian Archive
1: DFSG and the sections of the archive (free, non-free, contrib, non-us)
2: The different distributions (stable, etc.)
Part II: Packages and metadata
3: Package structure (source, binary, arch-dep/indep)
4: Control fields: source package fields
5: Control fields: binary package fields
6: Package dependencies: binary packages
7: Package dependencies: source packages
Part III: Packaging scripts and files
8: Maintainer scripts
9: Other miscellany: debian/rules, changelog, files, substvars, etc.
10: Configuration files
11: Shared libraries
Part IV: Other packaging issues
12: The operating system (cron, init.d, etc.)
13: Issues concerning files (permissions, links, scripts, etc.)
14: Documentation
Part V: Debian subsystem issues
14: X Windows policy
15: Perl policy
16: Menu policy
17: Emacs policy
...
Part VI: Programming guidelines and best practices
[There may be something which fits here]
Then each section could either have the structure:
Policy dictates
Discussion, useful information, guidelines, examples
or we could merge them, and have policy dictates all in the form MUST,
SHOULD, MAY, MUST NOT, etc., as in the RFCs. (As far as RC issues
goes, this could be marked by (RC) after the MUST/SHOULD/whatever,
with a catchall at the start of policy that the final decision on what
is RC rests with the release manager.)
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
website: http://www.maths.qmul.ac.uk/~jdg/
Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
Visit http://www.thehungersite.com/ to help feed the hungry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
