Bug#901160: Updating the description of the Standards-Version field
Usertags: normative discussion
Thank you for pointing out that Policy's description is out-of-date,
Ian, and for the patch. I agree that it captures the consensus we
established in that previous discussion, but it's not quite right for
Policy yet; see below.
Firstly, I think this text should go in section 4.1, and the description
of the Standards-Version field should have a link back to section 4.1.
The text in 4.1 is currently a bit strong about how often people have to
check Policy, so we can replace that with your new text.
On Fri, Jun 08 2018, Ian Jackson wrote:
> +For a package to have an old Standards-Version
> +is not itself a bug.
> +It just means that no-one has yet
> +reviewed the package with changes to the standards in mind.
> +The Standards-Version should not be updated
> +except after reviewing the applicable upgrading checklist.
The upgrading checklist explicitly states that it does not have
normative status, so a 'should not' requirement should not defer to it.
Also, IMO this should be 'must' rather than 'should' -- since it is pure
metadata, bumping the s-v without reviewing the changes to Policy can
only be counterproductive.
The Standards-Version must not be updated except after reviewing the
changes between the old and the new versions of the standards (the
upgrading checklist[hyperlink] can help with this task).
> +A very old Standards-Version
> +can mean that infelicities in the package are likely.
> +As a rule of thumb,
> +each package should be reviewed at least once per Debian release,
> +so a Standards-Version older than the previous Debian release
> +is indicative of work (if only review work) that needs doing.
s/As a rule of thumb, each package should be/It is recommended that each package be/
"Should" carries the weight of a bug of 'important' severity, but I
don't think that was your intent (and I don't think it should have
If others are happy with the changes in this e-mail I'll prepare a patch