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 <jel...@jelmer.uk> PGP Key: https://www.jelmer.uk/D729A457.asc
signature.asc
Description: PGP signature
