>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> Every package must comply with the MUST directives of the
Anthony> current policy, or it doesn't get released. Packages that
Anthony> don't comply with the current policy's SHOULD directives
Anthony> are buggy.
First I believe your reading of should is inconsistent with current
policy.
In this manual, the words _must_, _should_ and _may_, and the
adjectives _required_, _recommended_ and _optional_, are used to
distinguish the significance of the various guidelines in this policy
document. Packages that do not conform the the guidelines denoted by
_must_ (or _required_) will generally not be considered acceptable for
the Debian distribution. 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.
I believe it is consistent with that text for me as a maintainer to
close a normal bug opened against my package because I violate a
should guideline explaining why I had a good reason for doing what I did.
While generally a bug, it might not be a bug in my case.
Second, let me explain what I want out of the should/must terms in
policy as a user and maintainer and then try and describe how the current
system fails.
* I want a term corresponding to RFC MUST--violating that guideline is
always RC. As a maintainer I know that I need to change policy
before violating that guideline, and I better have so really good
reasons before bringing forward a proposal to change the
guideline. As a user, I have a big stick (RC bugs) to hit people
with when they violate the guideline.
* A term corresponding to RFC SHOULD. As a maintainer, I need to
think hard about violating the guideline and know why my case is
not the same as the general case that caused the guideline to be
created. Often, there may be text along with a should indicating
circumstances where the policy authors knew the guideline would be
inappropriate, but in other cases they realized flexibility was
needed and could not enumerate the cases where you might reasonably
want to violate the guideline. As a user, I still want a big stick
(RC bugs) to hit people with if they unreasonably violate the
guideline. Yes, this means the maintainer could simply assert that
their reason was sufficient, but really most maintainers try to be
honest about the handling of their bugs. A normal bug is not a
big enough stick; some should guidelines might be a significant
problem if violated for the wrong reasons.
* As a maintainer I want to have a general idea what guidelines are
shoulds simply because not all packages implement them and will
become musts. That gives me information about what I need to do
in the future. If Debian-policy has already decided that they would
like to eventually turn a certain guideline into a must and I
believe that I have a good reason (other than not getting around to
it) for violating that guideline that I should talk to
Debian-policy now. If I don't convince the list that my reason is
sufficient then I better think of something to do before the
guideline becomes a must.
My problems with the current policy are that it's not clear it
acknowledges the existence of the class of guidelines that have
exceptions other than not being implemented by enough packages. Also,
it's not clear to me that I have recourse as a user if a package is
violating a should in a way that creates a significant problem for
users of that packages. In some cases I might be able to open grave
(although not serious) bugs because the definition of grave only
requires that the release would be improved by removing the package
where as serious requires a specific policy violation--this might
actually be sufficient. Finally, the current policy does not convey
future intent of debian-policy to me as a maintainer. For example, I
believe this list has reached a consensus that it would like to turn
build-depends into a MUST and the only thing holding us back is the
number of packages that do not have build-depends currently. It would
be nice if the wording of policy let me know that the only reason the
guideline was not mandatory was existing packages.
