Dear Ubuntu Developers,
Imagine you land a bugfix in an SRU to Focal today, but leave out
Hirsute even though it is also affected. A user who subsequently
installs Focal, benefits from the bugfix, and then upgrades to Hirsute
will be regressed. Is this acceptable?
As a newer SRU team member, I never observed a requirement to also fix
Hirsute in such a situation to be documented policy[1]. So I'd been
taking it case by case.
It turns out that other, longer standing SRU team members considered it
to be a requirement all along, and therefore an omission in current SRU
documentation that such a requirement isn't explicitly stated.
I think it'd be useful to reach a conclusion on what our policy should
be in this case, document it, and then be consistent in SRU review
expectations. Please use this thread to provide feedback on this, and
then the SRU team can use this to make a decision.
Here's one consideration that might provide a compromise against the
effort required. Today, the same situation would apply to Groovy, except
that a user who is regressed still has the opportunity to upgrade to
Hirsute to fix the regression if it is fixed there. So it might be
considered sufficient to form a policy that says that a bugfix to an LTS
must also land in only the most recent stable Ubuntu release, rather
than in all later stable releases.
There's also the observation that fixing Focal but not fixing Hirsute
makes the situation better, not worse, by improving the experience at
least for the Focal users. An argument can be made that some improvement
is better than no improvement, and therefore such an incremental
improvement that is volunteered should be accepted. Counterpoint: the
user experience is harmed if a user installing Focal subsequent to the
bugfix landing in Focal, and therefore unaware of any bug, then upgrades
to Hirsute and is regressed.
Hence my suggestion of the compromise above. It seems unlikely that a
Focal user will upgrade to Groovy but have an issue in upgrading to
Hirsute. In fact that would be advisable anyway because Groovy had only
three months left when Hirsute was released. On the other hand, it's
quite normal for a Focal user to want to upgrade to Hirsute to get some
new feature, and that pressure will only increase after Impish is
released, because at that stage Focal will be as far behind as it will
be before the subsequent J LTS is released.
To avoid things getting too confusing, I've used Focal, Groovy and
Hirsute by example where Focal is the LTS, Groovy is still supported and
non-LTS and Hirsute is the current latest release and is not LTS. Any
policy would of course apply more generally, but today's is the most
complicated situation. I hope that it's clear how my examples
generalise.
Robie
[1] Note however that it is a documented requirement for feature
additions, as opposed to bugfixes, to land in all subsequent stable
releases. This is also a practical requirement if you bump the upstream
version (eg. if SRUing an upstream microrelease update), since there are
other problems introduced if version numbers during release upgrades go
"backwards".
