SRU shift report: 2020-09-23
robie.basak at ubuntu.com
Fri Sep 25 12:40:55 UTC 2020
Thank you for the encouragement!
On Thu, Sep 24, 2020 at 09:40:08AM -0400, Scott Moser wrote:
> In looking at the change myself, I think that tools to generate a
> patches/applied branch of the SRU upload would be very helpful here.
> If you could have done something like:
> $ git-ubuntu add-dsc --name=candidate cloud-utils-0.27-0ubuntu25.2.dsc
> $ git diff pkg/ubuntu/xenial-devel candidate/unapplied
FWIW, this partly already exists with:
git ubuntu clone cloud-utils
git ubuntu queue sync
git log -1 -p queue/xenial/unapproved/cd931cc
For packages available in git-ubuntu, this method provides the
equivalent of the "Launchpad diff" except that it also understands the
security pocket and won't inadvertently bundle already landed security
fixes. The queue tag will autocomplete, and the commit is automatically
based on pkg/ubuntu/xenial-devel so you don't need to specify that part.
This allows for easy comparison against what is in the archive already,
for example to compare what is being proposed in an SRU against what
landed in the development release.
What we don't have yet is an easy conversion to the "applied" branches,
which would make it easier to compare the _result_ of quilt patches
directly. "gbp pq" can be used for this, but needs some rearranging
first as it assumes you're working on a single packaging branch. Instead
I occasionally find myself iterating over "quilt push", "git add -Af"
and "git commit" by hand to do an "applied" comparison.
> Again, I respect the difficulty in reviewing large numbers of
> very different source code changes. But I disagree that this
> specific change should qualify as "Substantial diff (non-trivial change)".
> I'm willing to remove the test file if that makes this more clear, but
> personally I think the ease and usefullness cherry picking upstream
> changes into debian/patches justifies the added cost.
To be clear, there's nothing in the cloud-utils SRU upload that I saw
that I thought was wrong or that I thought you should do differently. As
I described on IRC this looks like one of unfortunate those cases where
you had to add an internal "feature" (a new non-trivial function) to fix
a bug. This just meant that I'd need to consider the new code in my
review which made the review a bit longer; that's all. It looked like
necessary pain for everyone concerned, in the same sense that all SRUs
are necessary pain.
 At a quick glance; as I moved on I didn't finish the review
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the ubuntu-devel