should vs must

[Sam Hartman <hartmans@mit.edu>]

>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:

    Anthony> --zYM0uCDKw75PZbzx Content-Type: text/plain;

    Anthony>  2) Sometimes it's appropriate to raise the bar on what
    Anthony> we want included in Debian; that's what the difference
    Anthony> between "MUST" and "SHOULD" is meant to reflect, packages
    Anthony> that break SHOULDs, well, shouldn't, packages that break
    Anthony> MUSTs, will be kicked out of the archive as soon as
    Anthony> someone (ie, me) gets around to it

There is an important difference between how you are viewing should
and how the current  policy document  views should.  I tend to notice
this difference  because  of work within the IETF, but I believe my
interpretation is supported by current text.

 Non-conformance with guidelines denoted by
      _should_ (or _recommended_) will generally be considered a bug,
      but
      will not necessarily render a package unsuitable for distribution.

One of the more obvious reasons for not following a should guideline
is that it's a new guideline and the maintainer hasn't gotten around
to following it.  However, I suspect there are significant classes of
guidelines that will always have exceptions.  It's generally a good
idea to follow this guideline and if you fail to follow the guideline
you'd better have a reason for not doing so.  If your reason isn't
good enough, then  we'll open a bug.

It's important for policy to support this distinction between shoulds
that  are because of attempted/evolving practice and shoulds that are
good ideas that may not apply to all situations.  It's important for
us to keep that in mind when we discuss the distinction between should
and must.