On Wed, Jun 16, 2021 at 02:11:36PM +0100, Robie Basak wrote: > Imagine you land a bugfix in an SRU to Focal today, but leave out > Impish even though it is also affected. A user who subsequently > installs Focal, benefits from the bugfix, and then upgrades to Impish > will be regressed. Is this acceptable?
[above quote modified to be current against the current stable release to help make the example clearer] Thanks all for the discussion. To wrap things up, the SRU team has agreed the following policy position, which I think continues the status quo but is more explicit and should help clarify the position for everyone. I will update the SRU wiki page accordingly. ---8<--- If a bug is being fixed in a particular stable release, we would like for all subsequent releases that are still supported to also be fixed at the same time. This is to prevent a user from facing a regression when they upgrade to a newer release. Exceptions: 1) When there are two subsequent interim releases If there are two subsequent interim releases that are both current, then, as a compromise, additionally fixing only the most recent one is acceptable. Rationale: a user facing this class of regression will at least have an upgrade path available to them that fixes it. 2) When you don't want to fix a subsequent interim release at all We recognise that making it a hard requirement to fix all subsequent interim releases would mandate more work, and that a team may not have the resources available to fix and verify (say) an LTS as well as a subsequent interim release that has fewer users. We wouldn't want to block a fix from landing at all, so we are not making it a hard requirement that subsequent interim releases be fixed. However, we strongly recommend that subsequent interim releases be fixed, and it is our expectation that normally uploaders will ensure this. If you are unable to do this, then please: 1) create and mark bug tasks against the subsequent affected releases "Won't Fix"; and 2) explicitly state in the bug that you are deliberately seeking to fix a release without fixing the subsquent releases. An SRU team member may then accept your upload at their discretion and on a case-by-case basis. If this is not done, then uploaders should expect an SRU review round trip while your intentions are clarified.
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel