Stable Release Updates on Xubuntu

From the moment an Ubuntu release (and flavors) reaches Final Freeze until the release is end-of-life ( EOL), updates are released following the “stable release update” procedure, or SRU. This process is documented on the Ubuntu Wiki. However, it can be intimidating for new and long-time contributors and also confusing for users. I’d like to explain this process from a Xubuntu perspective.

We currently have two packages going through the SRU procedure for Xubuntu 20.04 and 20.10. After you’ve read this article, consider checking them out and helping with verification.

• Xfce Weather Plugin
• Exo

Stable Release Update Procedure

1. Identify the “why”
2. Create or update bug reports
3. Package and upload the fixes for each release
4. Wait for the SRU team to review and accept the upload
5. SRU Verification
6. Wait for the SRU team to release the package to the -updates pocket

Identify the “why”

A common misconception about stable Ubuntu releases is that all bug fixes and new releases (small and large) will arrive via an update. There is no automatic process for these updates to land in a stable release. Further, any fixes and new features must be documented and tested according to the above procedure. As you might imagine, this can be a massive time sink.

Stable release updates specific to Xubuntu will generally be limited to high-impact bugs:

• Security vulnerabilities
• Severe regressions
• Bugs that directly cause a loss of user data
• External changes that cause the current version to no longer work

If an update meets these requirements, it is eligible to be updated with a Stable Release Update (SRU). Lower-impact bugs will generally not be considered for SRU but may be fixed in the backports pocket or the Xubuntu QA Staging PPA.

Create or update bug reports

If the bugs being fixed have already been reported on Launchpad, they will need to be updated with the SRU template. Other bugs and new features in an upload should open new bug reports. Due to the time-based nature of landing a fix and following the SRU process, it can be a significant setback to have to start over, so more information is better than less. When in doubt, fill it out.

The standard SRU template typically includes the following sections: Impact, Test Plan, Where problems could occur (formerly Regression Potential), and Other Info. These sections help others who may not be completely familiar with the software or bug to be able to test it and demonstrate that the upload and its regression potential have been sufficiently considered.

Once the bug reports are ready, the packages can be prepared and uploaded.

Package and upload the fixes for each release

The first packaging-related step for a Stable Release Update is ensuring the fix is already released on the current development release. This may not always be applicable, but it applies more often than not. Once the fix is verified in the development release, packages can be prepared for each affected stable release.

The packages are prepared with each bug fix linked in the Debian changelog. This will automatically update the affected bugs with status updates and tags and progress the bug status from In Progress to Fix Committed and later to Fix Released. The packages are then uploaded to the -proposed pocket and Xubuntu SRU Staging PPA.

Wait for the SRU team to review and accept the upload

The Ubuntu SRU team is a small and busy one! Sometimes, it may take a few days for the team to review and accept the upload to the -proposed pocket. Once the package has been accepted, start the 7-day clock. Even after verification, a package upload must wait a minimum of 7 days before it is accepted into the -updates pocket.

SRU verification

SRU verification can be completed by any Launchpad user and is recommended to get a fix released to the updates pocket sooner. Following the test cases documented on each bug report…

• If the fix is sufficient and there’s no regression, replace the verification-needed- release tag with verification-done- release. Add a comment describing the steps taken to verify the package.
• If the fix is insufficient or there are regressions introduced, replace the verification-needed- release tag with verification-failed- release. Add a comment describing steps taken and issues encountered.

An update is considered verified if it has at least two positive and no negative testimonials. If you’re affected by a bug going through SRU verification, please join in and provide feedback on the fix.

Wait for the SRU team to release the package to the -updates pocket

Once an uploaded package has met the 7-day minimum wait and has been verified, it is eligible to be reviewed and released by the SRU team. Again, this can sometimes take more than 7 days, but if it seems to be running unusually long, add a comment (but please don’t spam us) on the bug report to check-in.

Finally, updates are phased, which means that a release package update may not show up for a few days. Assuming no significant regressions cause the update to be halted, it should be available soon. Please be patient and respect that this process is designed to keep your computer running smoothly.

Wrapping Up

While not an exciting topic, I hope this provides some insight into the inner workings of a stable Ubuntu release. Let me know if you have any questions or if I got something wrong. If you’re working on another Ubuntu flavor or derivative, what does the post-development release process look like for your team?