[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Must and should: new proposal (was: Re: Must and should again)

On Mon, Apr 16, 2001 at 02:16:24AM +0100, Julian Gilbey wrote:
> I guess there are two conflicting desires here:
> (1) The Acting Release Manager's desire to have it clear what
>     constitutes an RC bug.
> (2) Developers' desires to know what "must" be done in all cases and
>     what "ought" to be done (but there may be exceptions), and what is
>     currently a "desirable thing" but is likely to one day become an
>     RC requirement.

A suggestion and a thought.  Suggestion first:

- Anthony's already indicated that he's not particularly bothered if
  we change the specific words used to indicate RC and non-RC, but he
  really wants the RC/non-RC distinction to remain in policy

- Others have suggested that they would prefer to have MUST and SHOULD
  retaining their IETF meanings

- So how about giving MUST and SHOULD their IETF meanings, allowing
  policy to state how things *ought* to be done to comply, and
  appending an asterisk to ones which are regarded as RC.  So
  everyone's needs are met: developers know what things really ought
  to be done to create a good package, and it's also clear which
  things are and are not considered RC.  As *examples*:

    Packages with app-defaults MUST* install them in ...
    Packages MUST install their documentation in /usr/share/doc ...
    Packages SHOULD comply with the FHS ...
    Every user-level binary MUST have a manpage ...

  (I can't offhand think of an example of a SHOULD*; perhaps something
  like the library-naming business: there may be specific instances
  where it has to be done differently, otherwise it's RC.  And don't
  flame me for this specific example, please; I know I may be wrong
  about it.)

  Then it's clear that to write a good package all of the above ought
  to be satisfied, but only normal-level bugs can be filed against
  anything other than the app-defaults stuff.

Does that possibility satisfy everyone:

- MUST and SHOULD change to the universally-recognised IETF meanings

- the distinction between RC and non-RC bugs is retained clearly

- it's clear what one ought to do to create a "good" Debian package

- there's no time component involved

- there's no longer a suggestion of using policy as anything other
  than a set of guidelines

And the thought, now an orthogonal one to the above stuff and not
really appropriate on -policy, but this is where it makes sense at
this point:

Did the ftpadmins ever consider the possibility of running lintian on
packages before allowing them into unstable?  I vaguely remember that
being discussed in the past.



         Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
       Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Reply to: