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

Re: Must and should again

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

      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.

Reply to: