Hi Sean,
On Wed, Dec 04, 2019 at 07:37:31AM -0700, Sean Whitton wrote:
> Thank you for working on lintian-brush and janitor.debian.net. Looks
> like it's going to save people a lot of time, especially for teams with
> lots and lots of packages.
>
> On behalf of the Policy team, I wanted to ask about the bot's attempts
> to respond to the out-of-date-standards-version Lintian tag. Presumably
> the bot isn't actually smart enough to read the Policy upgrading
> checklist and actually check that a package satisfies all the points of
> the new Standards-Version, so I guess that whenever the bot proposes
> bumping the Standards-Version field, the human reviewing the change has
> to go through the upgrading checklist and check that all the points are
> satisfied.
>
> However, the FAQ for the bot[1] says that "At the moment, the Janitor's
> merge proposal are still triggered by a human (after manual review)."
>
> Should this be read as saying that once the bot has seen more testing,
> you plan to stop manually reviewing its merge proposals, and just let it
> go ahead and submit them? Or will they always be manually reviewed?
>
> If the former, I wonder if the bot should stop trying to respond to the
> out-of-date-standards-version Lintian tag. I am concerned that
> maintainers receiving the MRs might assume that they don't need to look
> at the upgrading checklist in order to know that the change to
> Standards-Version is correct, and just go ahead and merge it. But
> bumping Standards-Version without any human looking at the upgrading
> checklist effectively renders the Standards-Version field pointless.
>
> Essentially, it seems to me that the out-of-date-standards-version tag
> is different from the other Lintian tags which janitor.debian.net is
> trying to fix, in that you can't see that a change in response to the
> tag was correct just by looking at the diff.
Thanks for the considerate e-mail; I share your concern that simply
updating Standards-Version renders it meaningless, and should be
avoided. I took measures to try to prevent that, and I'm interested to
hear whether you think those are sufficient.
The bot will only attempt to update the Standards-Version in a select
set of situations where it can verify that there are no
changes necessary to comply with the new standards version.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921971 for
the initial discussion about this.
The bot currently only supports upgrades between the
following standards versions:
* 4.1.0 => 4.1.1, if debian/changelog exists
* 4.2.0 => 4.2.1, no checks (just loosens a requirement for perl
files)
* 4.3.0 => 4.4.0, if the package uses debhelper
* 4.4.0 => 4.4.1, if there is only one Vcs field and none of the file patterns
in machine-readable debian/copyright refers to a directory[*]
In all other situations, it leaves the Standards-Version field alone -
requiring a human to deal with updating it.
These checks were implemented based on my reading of the policy
upgrading check list [1]. I'm hoping that it can upgrade between more
versions in the future, but of course in most situations a human will
need to be involved.
So while it verifies that the package is compliant with the
newer standards version ("violations"), it does not currently check
that there are no liberties provided by the newer version that the
package could use ("opportunities"). E.g. it doesn't refuse to
upgrade to 4.4.0 if there is a Vcs-Hg field without a branch specified
in the package, where the package maintainer may have wanted to set a
branch.
I do indeed also manually review all diffs before they end up in merge
proposals; at the time of writing I have no plans to stop doing this,
but this is more of a QA step and consists of a fairly casual review -
I don't expect to be spotting policy violations/opportunities
consistently at this step.
Please let me know what you think. I'm open to extending the
number of checks (e.g. to cover for possible "opportunities" like
setting -b on the Vcs-Hg field) or indeed to stop touching the
Standards-Version altogether, if policy team would still prefer that.
Cheers,
Jelmer
[1] https://www.debian.org/doc/debian-policy/upgrading-checklist.html
--
Jelmer Vernooij <jelmer@jelmer.uk>
PGP Key: https://www.jelmer.uk/D729A457.asc
Attachment:
signature.asc
Description: PGP signature