On Sun, Apr 30, 2000 at 11:36:45PM -0500, Steve Greenland wrote: > On 28-Apr-00, 04:10 (CDT), Anthony Towns <aj@azure.humbug.org.au> 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 <aj@humbug.org.au> <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
Attachment:
pgpJRulGtJzed.pgp
Description: PGP signature