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.
