[SRU] 2.67.1
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
snapd (Ubuntu) | Status tracked in Plucky | |||||
Focal |
Triaged
|
Undecided
|
Unassigned | |||
Jammy |
Triaged
|
Undecided
|
Unassigned | |||
Noble |
Triaged
|
Undecided
|
Unassigned | |||
Oracular |
Triaged
|
Undecided
|
Unassigned | |||
Plucky |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
=======
This is an SRU for Snapd 2.67.1
=======
This SRU started out as Snapd 2.67, but the follow-up bug fix release Snapd 2.67.1 is now available and should supersede 2.67 to speed up delivery of the best performing version.
The Snapd package qualifies as a SRU special case, https:/
Release preparation:
-------
Release branch preparation: https:/
Release notes: https:/
Lauchpad bugs addressed: https:/
Launchpad bugs impact & test plans:
- https:/
The release notes are generated from the list of all PRs that went into the release: https:/
Release Validation:
-------
Release branch test results: https:/
QA Beta validation Jira ticket: https:/
Cert testing: https:/
QA Deb testing on proposed: Deb testing will run on -proposed and update will be provided (covers amd64, arm64)
Release source packages on `ppa:snappy-
-------
Plucky: https:/
Oracular: https:/
Noble: https:/
Jammy: https:/
Focal: https:/
Release source packages on `ppa:ernestl/
-------
Plucky: https:/
Oracular: https:/
Noble: https:/
Jammy: https:/
Focal: https:/
All: https:/
---original---
=======
This is an SRU for Snapd 2.67.
=======
The Snapd package qualifies as a SRU special case, https:/
Release preparation:
-------
Release branch preparation: https:/
Release branch test results: https:/
Release notes: https:/
Lauchpad bugs addressed: https:/
Launchpad bugs impact & test plans:
- https:/
- https:/
- https:/
- https:/
The release notes are generated from the list of all PRs that went into the release: https:/
Excluded from release notes:
- Test improvements
- Internal changes (no external impact)
Release Validation:
-------
Release branch test results: https:/
QA Beta validation Jira ticket: https:/
Cert testing: https:/
QA Deb testing on proposed: Deb testing will run on -proposed and update will be provided (covers amd64, arm64)
Release source packages on `ppa:snappy-
-------
Plucky: https:/
Oracular: https:/
Noble: https:/
Jammy: https:/
Focal: https:/
Release source packages on `ppa:ernestl/snapd` (added LP: #<number> to changelogs):
-------
Plucky: https:/
Oracular: https:/
Noble: https:/
Jammy: https:/
Focal: https:/
Release targets:
-------
This release targets: Focal, Jammy, Noble, Oracular, Plucky
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
summary: |
- [SRU] 2.67 + [SRU] 2.67.1 |
Changed in snapd (Ubuntu Noble): | |
milestone: | none → ubuntu-24.04.2 |
I was reviewing the proposed upload against the admittedly outdated exception.
While I highly appreciate that the exception is being reworked, and getting
much more complete, and removing old cruft - I agree that in the short term for
the current upload we might want to go by the old exception to not stall even
more.
To make sense of all of it I sat together with Ernest as by chance due to my
sprinting he has been nearby. We have been cross Q&A-ing all kind of details,
to ensure the testing today is equal or better (usually it is the latter) to
what the original exception required.
We also discussed about the general stance of long term stability of behavior,
which I gladly learned is part of their team's approach anyway. There can always
be issues, but at least they are conceptually far away from any "just add things"
thinking.
We've dived into the testing that is done and I appreciate outlining so much
in the bug description - looking forward to the new exception making this line
up well. We identified a few weak spots which he took as action to resolve for
the current case as well as for the renewed exception.
While for this upload what is missing will be added manually, but there has been
great agreement like utilizing the autopkgtest more to get better cross arch
coverage and to get better notice of apparmor/system influences. All that will
eventually help to make these uploads more smooth.
All I've found gave me quite good confidence in the general approach, the
coverage they already have and to extend where it is needed to feel truly safe
for an SRU of that scale. What was left and will in the future be part of the
automation and the new SRU exception is listed in the following section which
Ernest will follow up on. As lessons learned from MIR rules, I give them numbers
so he can refer to them when providing the related info - this is not an order
or priority.
Next I checked the state of the archive, all is at 2.66.1 right now which means
we do not need to look at 2.66 -> 2.67 but only 2.66.1 -> 2.67.
Furthermore together we ensured I understand the sanitazion and mapping from
commits to changelog and to release notes. What they do is actually really great
but hard to follow if you do not know why/how. In the future their process will
provide the artifact (spreadsheet) of that journey so one can more easily follow.
Next I made sure that what I compare in git from https:/ /github. com/snapcore/ snapd.git
was comparable to the upload in the PPA. I've confirmed that the only
differences that mattered have been vendoring (in the package, not the repo)
and some dotfiles which are stripped when building the package.
Furthermore I checked if the further vendored code has brought any changes we
also would need to review, but there are none.
With that done I was reviewing the 167 commits, which of which the majority 44%
are tests for those new things or extending existing tests. What is left is an
equal amount of ~14% interface and component code (the actual development) and
about 6% bugfixes. The rest have been smaller features which I'd not list
individually. Those I was not reviewing with a POV of "is this go code nice"
which they hav...