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

Bug#930666: Please document consensus on use of dh sequencer



>>>>> "Sean" == Sean Whitton <spwhitton@spwhitton.name> writes:

    Sean> Let me try to express what I think the problem is.  What the
    Sean> first sentence says, given the equivalence of RECOMMENDED and
    Sean> SHOULD noted above, is "you should use dh unless there is a
    Sean> reason not to use dh".

    Sean> However, any SHOULD requirement in Policy implicitly has that
    Sean> structure: "you should X unless there is reason not to X".


That's not how I read policy at all.
>In the normative part of 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 to 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


No where in the above text do I see that if there is a good reason not
to do x, that x is not a non-RC bug in your package.
This is the key difference between how policy uses those terms and RFC
2119.

So, I think Russ is correct that what we're saying is that you should do
x unless there is an adequate reason not to.
If recommended in policy language actually meant that, we could say dh
is recommended, spend a bit of text giving examples of reasons why it
doesn't apply and be done.

I'd be in favor of changing policy so that should meant should x unless
there is a good reason not to do x, but that is a much much bigger
change.


Reply to: