Wednesday 23 September 2020

SRU shift report: 2020-09-23

On my SRU shift today, I'm disappointed to report that out of sixteen
packages I looked at, I didn't end up accepting a single one. Some of
this is because I ran out of time, but I am writing this report because
I think that with some help from you, we can do much better.

I'm aware that many consider the SRU queue slow and backlogged. In my
view, it looks more backlogged than it really is because so many uploads
are not ready to be accepted but continue to clog up the queue, and this
noise hides the SRU uploads that _are_ ready.

I appeal to uploaders to take the time to ensure that the full
documented SRU process has been followed *before* uploading. If you're
doing something exceptional that deviates from a routine SRU, then
please take the time to _fully_ document in the bug exactly what you're
doing and why it is required.

Specific summaries of my individual reviews below. Perhaps I have missed
something in individual reviews, in which case I welcome corrections. My
point though is a general one. I think the number of SRUs that could
have been straightforward but have been made unnecessarily complicated
could be reduced considerably by following the documented process and
thoroughly explaining exceptions.

## gnome-shell (Bionic)

I identified a possible problem when I first looked at this in August.
This might inadvertently introduce a regression. We have been awaiting
an analysis from a subject matter expert to review and confirm if there
is no problem, or re-upload fixing it if there is. Rejected from the
queue today since it has now been Incomplete for over a month.

Outcome: rejected from queue.

Feedback: please don't take this the wrong way. We don't have a great
way of tracking items in the queue that are blocked from proceeding, and
this results in SRU team members looking over and over again at the same
blocked items. We have agreed that to mitigate this, rejecting blocked
uploads from the queue is acceptable. Please do re-upload if/when you
consider an upload unblocked.

## ubuntu-release-upgrader (Xenial, Bionic)

Already accepted by someone else into Focal, so left for the SRU team
member already familiar with this change.

Outcome: deferred for another SRU team member.

## nvme-cli (Bionic)

Already accepted by someone else into Focal, so left for the SRU team
member already familiar with this change.

Outcome: deferred for another SRU team member.

## cloud-utils (Xenial)

Substantial diff (non-trivial change) will take considerable time to
review; postponed for a subsequent pass through the queue.

Outcome: deferred for a second pass over the queue[2].

## scilab (Bionic, Focal)

Complex proposed fix, including the bundling of unrelated fixes, will
take considerable time to review; postponed for a subsequent pass
through the queue[2].

However, I noticed that tdaitx later asked bdmurray in #ubuntu-release
to reject this from the queue. I don't understand why, but I assume this
means it's not ready, so don't need to consider this further.

Outcome: no longer needs review.

## network-manager (Focal)

Missing regression analysis contrary to documented SRU process. I'm now
the second SRU reviewer to look at this and be unable to accept.

Outcome: SRU processing is blocked.

Feedback: "None" is *never* acceptable as your regression analysis. If
you find yourself saying this despite having read our process
documentation, I suggest that you ask others for help on IRC. Uploading
without filling this in will just cause unnecessary delay to your SRU.
Sponsors: please do not upload until the SRU documentation is ready;
this would help other SRUs get processed faster.

## livecd-rootfs (Xenial)

Trivial change, but for a complex issue with many packages impacted. I
could not find any documented reason for this particular change being
required, even though it is mentioned here and there in the bug. However
I know that Andreas has been working directly with Steve on this, so I
leave this for Steve's review.

Outcome: I consider this blocked for me, but easier for Steve to unblock
than anyone else, as he's already familiar with what's going on.

## tracker (Focal)

New feature released in microrelease update, contrary to our
understanding of the microrelease exception. Chris already asked about
this. I'm now the second SRU reviewer to look at this and be unable to
accept.

Outcome: SRU processing is blocked.

Not feedback: it's not reasonable to expect the uploader to get back to us
within a day, but our current process is suboptimal in that every one of
these cases ends up being looked at again on every shift. In the long
term I'd like to fix this somehow so that we don't end up looking again
until the person driving the SRU considers the matter unblocked again.

## zfcpdump-kernel (Focal)

Groovy and Focal tasks marked "Won't Fix", so this didn't make any
sense. I need to verify the fix is landed in Groovy, or is otherwise on
the way or not relevant, as this is an SRU requirement. Asked the
uploader on IRC, who corrected them to Confirmed. However there I still
have outstanding questions, such as why this isn't being fixed in Groovy
first. Asked in the bug.

Outcome: SRU processing is blocked.

Feedback: this seems like an unusual case, so please provide full
documentation of what is going on and why it is needed in an SRU on the
points that differ from a normal SRU.

## gnome-shell (Focal)

Blocked on gnome-shell microrelease discussion[1].

Outcome: SRU processing is blocked.

## yaru-theme (Focal)

It isn't clear to me why this needs an SRU because there's no
explanation of why it needs to track gnome-shell. I see that it is
usually SRU'd using regular bugfixes, but has once before been SRU'd in
this manner with no explanation given in the previous bug. Asked for an
explanation. In any case it doesn't make sense to accept it until the
gnome-shell microrelease update situation is resolved.

Outcome: SRU processing is blocked.

(this has since kindly been clarified in the bug, but remains blocked on
the gnome-shell microrelease question)

## base-files (Xenial, Bionic, Focal)

I had thought this was the same as livecd-rootfs, but I'm now told it
isn't. Nevertheless it's all related to the same complex change, so I
think it makes sense for just a single SRU team member to be familiar
with all the moving parts, rather than for all of us to individually
spend time getting fully familiar.

## pulseaudio (Focal)

This initially seemed like a proposed change in behaviour that upstream
didn't accept because of an upstream feature freeze, so seemed
inappropriate for an SRU. On a deeper look, it looks like it's
acceptable on a hardware enablement exception, since based on the diff
the hardware specifics weren't previously understood by pulseaudio. The
SRU documentation looked OK. But then on reviewing the diff I found
further changes not initially reviewed. It looks like two SRUs have been
included in this upload with two separate changelog entries, only one of
which appeared in the changes file. This will break the SRU release
process, so I rejected this upload since it needs fixing up first.

Normally I might spend some time fixing this up as it's just metadata
that needs adjusting and reuploading (subject to the review of the other
changelog entries which I have not done), but today I'm focused on
getting through as much of the queue as possible, so I moved on.

Outcome: rejected from the queue.

Feedback: if multiple people work on an SRU, it is cleanest and easiest
to coordinate and then upload the changes together with a single
changelog entry. You can still use multiple bullet points and the square
bracket notation to credit individual developers as desired. This way it
isn't possible to get the upload wrong by omitting "-v<version>" which
would otherwise be required. An exception to this is if the upload is
intended to supersede an upload already in the proposed pocket. In this
case the previous version number is "burned" and a new one must be used,
with the changelog adjusted and "-v<version>" used as appropriate to the
specific situation.

## torbrowser-launcher (Focal)

I helped the contributor with this one previously, and am pleased to see
it's been sponsored. Unfortunately it's missing the LP bug reference,
but also the contributor has since mentioned in the bug that an
additional fix appears to be needed. It seems that the SRU needs to be
delayed then, and I asked in the bug to confirm.

I didn't reject this from the queue because the contributor is new to
Ubuntu process so I didn't want to confuse them further in case it turns
out that a reject is not needed.

Outcome: SRU processing is blocked.

Feedback: I could have spotted the missing bug reference myself
previously, but didn't look throroughly as I assumed the sponsor would
do that. When sponsoring, please check that the documented SRU process
steps have been followed before uploading.

## openjfx (Focal)

I think I understand the problem that needs to be fixed here. However I
do not understand why a backport from Groovy is being proposed, when
usually SRU policy requires targeted fixes only. If an exception to
usual SRU process is being requested, then this needs to be explained
and a justification given. Otherwise, how can I review the request
except to conclude that the upload violates SRU policy and must be
rejected?

Outcome: SRU processing is blocked.

Feedback: if deviating from the norm, please give specific explanations
as to why you are requesting this.

## libsedjda-java/pdfsam (Focal)

Requires a major version bump in a dependency to fix. The uploader did
look at reverse dependencies in the archive, but this change may also
have implications for users consuming the dependency directly that I
think need to be considered. I've asked in the bug.

Outcome: SRU processing is blocked.

Feedback: while we don't have a strictly defined "interface" that we
want to avoid breaking, I think we should consider users consuming
library packages directly as well as reverse dependencies. It may be the
case that changing behaviour is the least worst option and we'll have to
break any users consuming the library package directly, but if so then
this case should be considered and weighed in the regression analyais.

---

[1] https://discourse.ubuntu.com/t/scope-of-gnome-mru/18041

[2] It is rare that I get time for a second pass over the queue; however
I would prefer to promptly process more straightforward SRUs than to
never look at them by spending all my time doing reviews for complex
SRUs. I do usually end up doing extensive reviews for complex SRUs
anyway at other times; of course these take longer so I get through them
at a slower rate.