Reviewing SRUs using git-ubuntu

[Robie Basak]

I've been asked to write up how I use git-ubuntu to review SRU uploads.
This is mainly of use only to other members of the SRU team.

There are just two common steps:

 1. I use `git ubuntu clone <package>`. This step gives me the normal
    git-ubuntu repository for the package, but doesn't include the
    unapproved SRU upload.

 2. Entering the git directory, I run `git ubuntu queue sync`. This
    pulls in, as `queue/` tags, the uploads from the unapproved queues
    as single commits based on the tips of the corresponding series'
    `-devel` branches.

At this point, you have the Unapproved upload(s) in your git tree and
can examine it/them in any way that you wish using regular git commands.
Here are some examples:

 * `git log -1 -p q<Tab>f<Tab>` shows me the "diff" of the Focal Unapproved
   upload. If the upstream orig tarball is being replaced (eg. for an
   exceptional major update), I can append `-- debian/` to see packaging
   changes only[1].

 * `git show q<Tab>f<Tab>:src/foo` shows me the `src/foo` file as it
   appears in the Unapproved queue. This is useful when I'm looking at
   the diff from the previous example, but want to see wider context.

 * `gbp pq import` can be used to flatten quilt patches to use git to
   make similar inspections with regard to the effect of quilt patches,
   and how they might vary between the upload and other existing branch
   tips.

 * `git range-diff pkg/ubuntu/focal..q<Tab>f<Tab>
   pkg/ubuntu/bionic..q<Tab>b<Tab>` shows me the differences between
   what was being proposed to be changed in Focal and what is being
   proposed to be changed in Bionic. This is really useful when the same
   SRU is landing in two series at once. I only need review it once (I
   usually use the most recent series being SRU'd), and then following
   that I only have to review the differences when considering the other
   series.

 * If I want to see how a fix in an SRU differs from a fix in the
   development release, then I can use `git diff pkg/ubuntu/devel
   q<Tab>f<Tab>` - possibly limiting the output to a single file by
   using something like `-- debian/rules`.

 * If review changes are needed, I can save the queue tag by tagging it
   with a name meaningful to me, ask for the changes, run `git ubuntu
   queue sync` again, and diff my old tag with the replacement queue tag
   to see what the uploader changed. This saves me from reviewing the
   whole thing again.

After review, I use `sru-review --no-diff` to accept the upload, as it
does some additional automated checking and I don't want to miss those.
At some point, I'd like to integrate its functionality so it can all be
done from a single tool.

## Further background

 * The queue tag names generated by `git ubuntu queue sync` are intended
   to be autocomplete-able. They are tags because multiple uploads for a
   single source package can exist in the queue at once, and adding
   further commits to them doesn't usually make sense. To disambiguate
   they are suffixed by a unique string, but in the common case you can
   ignore this and just use autocomplete as there will be only one.

 * `git ubuntu queue sync` will delete local tags that no longer exist
   in the queue, bringing the local set of queue tags in "sync" with the
   queue. If you want to keep some specific old queue uploads around
   locally, you can tag them yourself with names that are meaningful to
   you. There's also a `--no-trim` option that skips the "delete
   obsoleted tags" part of the sync.

 * In the rare case that the parent of an imported queue tag needs to be
   somewhere else, `git ubuntu queue sync` has various options to help
   with that. It can also import from the New queue, though that only
   really makes sense for package renames and similar types of corner
   cases.

 * Pocket copies are automatically followed, so there is no change to
   the workflow for these cases. I suppose the SRU team ought to check
   that any binary pocket copies have been built in an appropriate way,
   but I don't think we have any process for that in the established
   non-git-ubuntu method either at the moment, except for manual
   observation and checking.

 * Since we aren't using Launchpad-generated diffs, and the git-ubuntu
   importer already understands the "parent" of an upload, the diffs are
   generally correct and don't have the "includes security updates"
   issue we have with Launchpad-generated diffs in that particular edge
   case.

 * Since git is generating the diffs and understands and represents
   symlinks well, we can easily spot if symlinks have been accidentally
   flattened in an upload.

 * These steps only work if the package in question is already being
   imported by git-ubuntu. Right now, most of universe is yet to be
   imported. As we expand coverage, I'm pondering automatically
   including any package that has an upload in an SRU queue. This might
   work well to effectively prioritise packages that are actively
   maintained.

Robie

[1] In the case of a version 3.0 package, at least.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20210219/36e22454/attachment.sig>