>>>>> "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.