On Sun, Jun 10, 2018 at 01:16:07AM -0700, Sean Whitton wrote: > Here is the patch for seconding: > > > From 3bad0c91264c707ee163af93e45d3b53e5e4f880 Mon Sep 17 00:00:00 2001 > > From: Sean Whitton <spwhitton@spwhitton.name> > > Date: Sun, 10 Jun 2018 08:11:52 +0000 > > Subject: [PATCH] update description of usage of Standards-Version field > > > > --- > > policy/ch-controlfields.rst | 3 ++- > > policy/ch-source.rst | 30 +++++++++++++++++------------- > > 2 files changed, 19 insertions(+), 14 deletions(-) > > > > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > > index 0771346..ecac5de 100644 > > --- a/policy/ch-controlfields.rst > > +++ b/policy/ch-controlfields.rst > > @@ -521,7 +521,8 @@ Their syntax and semantics are described in > > ~~~~~~~~~~~~~~~~~~~~~ > > > > The most recent version of the standards (the policy manual and > > -associated texts) with which the package complies. > > +associated texts) with which the package complies. See > > +:ref:`s-standardsversion`. > > > > The version number has four components: major and minor version number > > and major and minor patch level. When the standards change in a way that > > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > > index e3b1981..7484772 100644 > > --- a/policy/ch-source.rst > > +++ b/policy/ch-source.rst > > @@ -10,18 +10,27 @@ Source packages should specify the most recent version number of this > > policy document with which your package complied when it was last > > updated. > > > > -This information may be used to file bug reports automatically if your > > -package becomes too much out of date. > > - > > The version is specified in the ``Standards-Version`` control field. The > > format of the ``Standards-Version`` field is described in > > :ref:`s-f-Standards-Version`. > > > > -You should regularly, and especially if your package has become out of > > -date, check for the newest Policy Manual available and update your > > -package, if necessary. When your package complies with the new standards > > -you should update the ``Standards-Version`` source package field and > > -release it. [#]_ > > +This information may be used to file bug reports automatically if your > > +package becomes too much out of date. > > + > > +For a package to have an old Standards-Version value is not *itself* a > > +bug, however. It just means that no-one has yet reviewed the package > > +with changes to the standards in mind. > > + > > +When updating existing packaging, the Standards-Version must not be > > +updated except after reviewing the changes between the old and the new > > +versions of the standards and updating your package if necessary (the > > +:doc:`upgrading-checklist` can help with this task). > > + > > +A very old Standards-Version can mean that infelicities in the package > > +are likely. It is recommended that each package 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-pkg-relations: > > > > @@ -695,11 +704,6 @@ according to this convention, the C source code of an executable > > ``checksum/util`` is to be located at > > ``debian/missing-sources/checksum/util.c``. > > > > - > > -.. [#] > > - See the file ``upgrading-checklist`` for information about policy > > - which has changed between different versions of this document. > > - > > .. [#] > > Rationale: > > > > -- > > 2.14.2 seconded. (with or without the sentence about filing bugs.) -- cheers, Holger, who wants to automate everything as much as possible, including filing bugs.
Attachment:
signature.asc
Description: PGP signature