It's been a while since I did one of these. It takes a while to write it
up that I could be spending on reviewing more SRUs, but I did also get
feedback that my last post was helpful. So I'll try to continue doing
these now and again.
As with last time, unfortunately most of the SRUs I looked at were
unable to make progress for some reason or other.
General themes:
* Missing status/explanation for releases subsequent to the one being
SRU'd. To avoid users facing a regression on upgrade, we'd like to
ensure that subsequent versions are already fixed, or if it is
necessary not to (eg. development release closed, not doing interim
release deliberately) then an explanation would really help. Also see
[1].
* Ambiguity on testing: what exact test steps were performed, and with
what versions? Was testing done with the actual builds that users
would use after this SRU lands? Does the testing cover general use of
the package, as well as the bug being fixed?
Today I started with the pending-sru report. I only considered entries
in the report that were fully green (ie. marked
"verification-done-<series>"). As long as the SRU queue is backlogged, I
consider it better to focus on these rather than try to progress the
ones that others can drive.
## rocr-runtime
This is finally verified in Kinetic - I remember looking at it again and
again over a number of shifts. But it's not aged yet for Kinetic even
though it is for Jammy, and unless we're in some reason to be hurried I
would release Kinetic first to avoid users facing a regression when they
upgrade[1].
Outcome: SRU processing is pending ageing.
Feedback: we discussed what we should do about interim releases and SRUs
on this list, found a compromise, and expectations are documented[1]. We
could speed up review cycles if all uploaders were familiar with it.
## apport
Outcome: deferred for a second pass over the queue (but I didn't get to
that).
## autopkgtest
The bug task is New for Mantic and no indication in bug comments as to
whether it is fixed in Mantic or not. Asked in a comment.
Outcome: SRU processing is blocked.
Feedback: please make sure your upload is marked Fix Released in the
development release before uploading, or if that's not possible, then
there's an explanation in the bug.
## oss4
This is blocked on Andreas' request (and followup) for the status for
newer releases.
I'm not sure why Andreas' question has not been addressed. Are the
appropriate people subscribed to the bug? It looks like the sponsor is
not.
To help with this case I am waiting on an MP that will automatically
subscribe uploaders to SRU bugs that they sponsored[2]. In the meantime,
it would help with sponsors did this themselves.
Feedback: if you're driving an SRU, or sponsored it for someone else,
please track it for followups.
Outcome: SRU processing is blocked.
## alsa-ucm-conf
There has been discussion/confusion over what kernel this should be
tested against. I don't want to release this without being certain that
the version being released has been verified against the appropriate
kernels from the archive, but the verification reports do not explicitly
state what versions were used. I remember a prior case of a severe
regression caused by this kind of ambiguity (the version actually tested
wasn't appropriate and resulted in a false negative), so I think it's
appropriate to push hard for an unambiguous verification comment,
especially when, as in this case with the kernels, there are multiple
versions floating about, including verification reports using locally
built kernels.
Outcome: SRU processing is blocked.
Feedback: please ensure that when you verify SRUs you specify exactly
what you did and state the relevant version numbers. Saying something
like "I followed the Test Plan and the test passed with version $v" is
fine since that unambiguously states what you did (in this case stating
kernel versions would also be necessary). Just flipping the bug tag
leaves ambiguity. We also expect SRUs to be tested entirely against the
archive, not against local or other builds.
## iptables
I think there are two things that we should be doing in SRU
verification:
1) Verifying that the bug we're trying to fix really is fixed, to avoid
having to push another update with further regression risk and
inconvenience to users.
2) Verifying that we haven't regressed unrelated functionality of the
package. A smoke test is about the most that is usually practical if the
package doesn't already have automated tests.
Usually the Test Plan implicitly performs the latter as part of the
former, or there's an automated test that covers the latter. But
sometimes this isn't the case and that's when I look for the latter to
be done explicitly.
In this case, I looked to see how the Test Plan might cover the latter,
and I didn't find anything. There are autopkgtests but they don't seem
broad enough to test basic functionality of iptables itself, and the
build log doesn't seem to mention a build-time test suite.
The result of releasing a regression in iptables would be severe, as
users' networking might be impacted such that they cannot
straightforwardly receive a regression fix. I'm not comfortable
releasing this without some confidence that somebody or some thing has
actually checked that iptables still works in proposed! So I asked for
that in a comment.
Outcome: SRU processing is blocked.
Feedback: documentation would have helped.
Followup: Andreas mentioned that he thought the latter case was
adequately covered by the autopkgtests. I didn't see any documentation
on that at the time, though, and I had spent a bit of time looking
around including a look at the source tree.
## swtpm
This was correctly marked Fix Released in Mantic, but I couldn't find
any explanation of how this was the case. I was concerned the status
change was an accident, so I dug into this and found that the relevant
code had substantially changed, the issue didn't appear present in the
new code and so the status was likely correct.
Outcome: SRU released.
Feedback: there was nothing wrong procedurally here. There's no
requirement for an explanation. But it's common either to see the bug
automatically closed with a changelog entry, or for someone to leave a
note stating which upstream version the bug was fixed in, and I find
these useful!
## dovecot
This FTBFS on amd64 according to the pending-sru report, but was marked
verification-done. It looks like it was verified on arm64 only. Asked in
the comment for the amd64 side to be looked at.
Outcome: SRU processing is blocked.
Feedback: there's nothing procedurally wrong here. But perhaps the amd64
build failure hadn't been noticed? The pending-sru report[3] collates
the status of everything together, and will flag build failures,
autopkgtest failures, and any outstanding SRU verifications. Please keep
an eye on that - usually the (backlogged) SRU team won't consider
releasing an SRU until it is green and has no warnings in this report.
## mokutil
This one took me some time to understand. FTBFSes were noted in the
pending-sru report but these architectures were not built previously so
there is no regression. The verification seemed to start in the middle
of Test Plan with previous steps not detailed if they were followed, but
eventually I concluded that what was done is equivalent. Released to
Jammy.
Outcome: SRU released.
Feedback: precise documented adherence to the Test Plan would make it
easier to confirm that the package is ready for release.
## wordpress
There was no mention of Kinetic, but I looked at the sources and found
that the patch is already applied in Kinetic. Released to Jammy. I added
a bug task for Kinetic and marked it Fix Released with a comment for
clarity.
Feedback: it would be helpful to explicitly state the status of
subsequent releases with a reason - this would save the SRU reviewer
the time needed to investigate to find the answer to this question. See
also our policy on newer releases[1].
Outcome: SRU released.
## software-properties
OK to release. Kinetic not mentioned but I happen to know it's not
relevant for the cloud archive.
Feedback: it would be helpful to explicitly state the status of
subsequent releases with a reason - in the general case this would save
the SRU reviewer the time needed to investigate to find the answer to
this question, although in this case I happened to know the answer. See
also our policy on newer releases[1].
Outcome: SRU released.
## tepl
This one was a bit puzzling since it was uploaded to Lunar originally
but actually landed in Mantic and looks like a copy back to Lunar to fix
the issue. Actually that seems all fine and correct and released to Lunar.
Feedback: none
Outcome: SRU released.
## python-tz
This is still waiting for autopkgtest failure investigations.
Outcome: SRU processing is blocked.
Feedback: none
## curl
This is still waiting for autopkgtest failure investigations.
Outcome: SRU processing is blocked.
Feedback: none
---
There ends the SRUs that looked like they were in a releasable state.
Next, I started looking at the unapproved queues, but I didn't get very
far here before the end of my shift.
## yaru-theme
This included changes that had no accompanying documentation or
explanation, and there was no special case documented[4].
I asked around SRU team members and nobody else seemed to know either.
It seemed to me that adding documentation would require a re-upload
since there would need to be a changelog change, so I rejected this
upload.
There was further discussion in #ubuntu-release and the final outcome of
how we're going to fix this package in Jammy is not concluded.
Outcome: rejected from queue.
Feedback: regardless of the eventual outcome, please note that the SRU
team cannot handle special cases without an explanation that we can
discover through the SRU documentation. We would like for SRU team
decisions and expectations to be consistent, but we cannot do that
without documentation and a pointer to that documentation. Even if some
SRU team member handled something in the past, if we don't know if it
was handled and how it was handled, we cannot be expected to it the same
way this time. Even if we did know who previously handled it, during an
SRU shift that person is often not available.
---
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Newer_Releases
[2] https://code.launchpad.net/~racb/ubuntu-archive-scripts/sru-autosubscribe/+merge/441467
[3] https://ubuntu-archive-team.ubuntu.com/pending-sru.html
[4] https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
