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".
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
