Hello, everyone I am reaching out to discuss some changes to the ubuntu-advantage-tools package SRU Exception. (https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates)
1. The first thing to note is that the link above is not listed as an SRU exception in the SRU page itself: ( https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases). I would say it would be nice to include it there. 2. Some of the references in the exception page mention the GitHub repository as ubuntu-advantage-client. That was renamed to ubuntu-pro-client, and this change could be reflected there. 3. The bug template still has the "old names?" for the last sections (such as Regression Potential) - and could be updated to the "What could go wrong" and "Other info" to match what is in the SRU page instructions. A couple other changes are related to the process itself, and we would like to update them to match what has been done in the past SRUs already: 4. The exception defines that a single Launchpad bug will be used to track the SRU, and " if there are very important bugs that are deemed worthy of reference they too should be included in the change log". But "very important" here is not well defined. Today, for every SRU, the team sees value in listing all fixed Launchpad bugs in the changelog, independent of the importance, reach, severity, etc. The reason we do this is to explicitly verify, during the process, that all of those bugs were fixed (as some of them may not be covered in integration tests for several reasons, and may require manual testing). We would like to change that part of the exception to reflect this behaviour: the main SRU bug tracks the whole process, and integration tests guarantee functionality for the verification, but individual bugs are treated individually. 5. The features/ folder in the codebase is where the integration tests are stored. Those tests sometimes need to be changed to better accommodate the status of the services provided by the client. During SRUs, u-a-t has a singe MP in Launchpad, and the same code is delivered to all releases. The source package contains the features/ folder and the integration tests. Those tests are excluded when creating the binaries - so they do not land anywhere in the SRUs. The very same tests are used to verify the main SRU bug. Thus, in merge requests, integration test changes will be present. In the past, we had situations where we needed to SRU bugfixes, and for complete distinct reasons we had to change some integration tests - sometimes it may happen that the client itself didn't even change a particular functionality, but the service itself did, so the client needs to reflect it in the integration. This led to confusion, among sponsors and SRU reviewers, and delayed the process more than we would like to. We would like to add a paragraph to the SRU exception stating that the features/ folder: - cannot be removed from the source package, because it contains tests that verify the functionality, matching what is in the package, - are removed at build time and don't end up anywhere in the binaries, and thus - don't need a throughout strict review from sponsors/SRU reviewers. Those people can still look at the changes there to understand what we are testing (and make sure they trust it, of course), but don't need to be extra strict or worried about those changes as they would be when reviewing the resto of the source code. - should not generally be pointed as a reason to block a SRU We would like to hear opinions about those points, and know how to proceed to change anything that is agreed. Thanks in advance for your attention, []s Renan
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
