should vs must
>>>>> "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.
Reply to: