Le 16/06/2021 à 15:11, Robie Basak a écrit :
> 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. So I'd been
> taking it case by case.
Isn't that the same topic that was discussed back then on
> 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.
In that discussion Steve stated that SRUing to $currentstable should be
the default but not a requirement...
> 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.
I think that would be a welcomed improvement to no require stable-1 to
get SRUed so thanks for the proposal! Speaking from a desktop
perspective it would allow us to focus on the series where most our
> 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.
I'm unsure the $currentstable should be a strong requirement rather than
a recommendation though for the reason discussed in the emails mentioned
before, you might end up pushing developers to delay their LTS fixes by
another cycle to avoid the extra workload which at the end doesn't
The 'user upgrades from a LTS to a new serie and hits a bug which didn't
exist in the LTS' is a problem we will have in any case. Software change
and you will have behavior changes and new problems coming from new
series, I don't think the lack of a SRU fix which was judged not
important enough by the developer to justify a SRU to a non LTS is what
is going to make the difference
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel