On Sun, Apr 30, 2000 at 11:36:45PM -0500, Steve Greenland wrote: > On 28-Apr-00, 04:10 (CDT), Anthony Towns <[email protected]> wrote: > > Comments, seconds, changes, etc appreciated. (I am following this list, > > btw) > In general, I approve of the concept and the edits you've made.
Cool.
> As a matter of esthetics, I think <em></em> around every occurrance of
> "must", "should", and "may" is distracting and ugly.
The main reason I did this was actually to make sure most of the `musts'
would show up in the diff. :)
> Actually, I'd like a better definition than "must/should/may"
> corresponding to "important/normal/wishlist" bugs. Just grabbing the
> standard verbiage from an RFC should be sufficient.
I actually agree with this, and I was kinda hoping someone would offer
alternative ways of phrasing it. I'm not sure that the RFC stuff is
quite what's needed though.
Standard RFC verbiage (from rfc2119):
] 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
] definition is an absolute requirement of the specification.
]
] 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
] definition is an absolute prohibition of the specification.
]
] 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
] may exist valid reasons in particular circumstances to ignore a
] particular item, but the full implications must be understood and
] carefully weighed before choosing a different course.
]
] 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
] there may exist valid reasons in particular circumstances when the
] particular behavior is acceptable or even useful, but the full
] implications should be understood and the case carefully weighed
] before implementing any behavior described with this label.
]
] 5. MAY This word, or the adjective "OPTIONAL", mean that an item is
] truly optional. One vendor may choose to include the item because a
] particular marketplace requires it or because the vendor feels that
] it enhances the product while another vendor may omit the same item.
] An implementation which does not include a particular option MUST be
] prepared to interoperate with another implementation which does
] include the option, though perhaps with reduced functionality. In the
] same vein an implementation which does include a particular option
] MUST be prepared to interoperate with another implementation which
] does not include the option (except, of course, for the feature the
] option provides.)
One problem is that the difference between MUST and SHOULD is different
for Debian policy. "I'm not in the mood right now" is a valid reason not
to include a manpage, in a package, but it's probably not an adequate
reason to ignore an RFC's recommendation.
What I had was:
In this manual, the words <em>must</em>, <em>should</em>,
and <em>may</em> and the adjectives <em>required</em>,
<em>recommended</em> and <em>optional</em> are used to
denote the significance of each particular requirement of
Debian policy, as follows. Except in exceptional
circumstances, bugs may be filed against packages not
adhering to a particular policy requirement with a severity
of <em>important</em>, <em>normal</em> or <em>wishlist</em>,
respectively.
Maybe something more like:
In this manual, the words *must*, *should* and *may*, and
the adjectives *required*, *recommended* and *optional*, are
used to distinguish the signifance of the various guidelines in
Debian policy. Packages that do not conform to policy guidelines
denoted by the word *must* (or *required*) will generally not be
considered acceptable for the Debian distribution, but packages
should generally adhere to most of the guidelines denoted
by *should* (or *recommended). Guidelines denoted by *may*
(or *optional*) are truly optional, adherence is left to the
maintainer's discretion.
These classifications also map neatly to the bug severities
*important* (for *required* items), *normal* (for *recommended*
items) and *wishlist* (for *optional* items).
Better rephrasings would be appreciated, but I would like to keep the
link between "must" and "severity: important".
> > + Every package <em>must</em> have a maintainer. This person
> > + or group is responsible for the package and should ensure
> > + that it is policy compliant.</p>
> Isn't this the subject of a long-standing flamewar? I think your change
> is de-facto what we do, but slipping it in via a typography change may
> lead to discomfort. (I'm *not* trying to restart this flame, and I truly
> believe that Anthony is just trying to document existing practice, not
> really attempting anything sneaky, but it could be viewed that way.)
Actually I was under the impression the flamewar had been resolved, but
just not documented. Nevermind.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
pgp9mg0NuhW50.pgp
Description: PGP signature
