[ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Aaron Rainbolt]

On 11/24/23 21:41, Steve Langasek wrote:
> On Fri, Nov 24, 2023 at 12:20:53AM -0600, Aaron Rainbolt wrote:
>
>> SRUs in packages used by flavors (including flavor-specific packages) are
>> also common.
> Speaking as a member of the SRU Team as well, I don't actually see evidence
> of this.  There has been a run of SRUs right at the time of the mantic
> release, related to release upgrades; and there was also a recent Lubuntu
> SRU to lunar to fix *notifications* for release upgrades; but I can't think
> of any other examples in the past few years.  This might be because it
> happened that all of them were processed by other members of the SRU Team,
> but that's statistically unlikely.  From my perspective, SRUs of core
> packages in main are much more common.  Can you point to something I've
> missed showing that flavor package SRUs are happening?

There are at least two high-profile fixes done in Lubuntu 22.04 via SRU, 
both of which were accepted by Chris Halse Rogers (RAOF).

There was a Calamares version update done via SRU in Lubuntu 22.04: 
https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1992507

There was an SRU for a highly problematic updater bug for Lubuntu 22.04 
that resulted in freezes when running updates and update notices not 
appearing anymore after an interrupted update (not do-release-upgrades, 
just normal package updates): 
https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2002255

tjaalton also helped out with an SRU for an updater problem when 
packages were to be removed: 
https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2012823

Together with the two SRUs you noted, this is at least *five* bugfixes 
pushed through by the Lubuntu team into the LTS over a year-and-a-half 
period, to keep the LTS working well for our end-users.(There may be 
even more I'm not aware of or don't remember, the ones I listed are just 
ones that were easy for me to remember and/or find.)

We also maintain a Backports PPA for newer versions on LXQt for 22.04, 
which can be enabled by users manually via add-apt-repository (it's not 
enabled by default and never will be per TB policy). This involves 
backporting the entire LXQt stack to Jammy to help our users have a 
better experience with the LTS if they have to use the LTS and don't 
want to use interim releases. Ubuntu Studio has a similar Backports 
repository delivered via a PPA for some of the software it ships. 
Kubuntu also has something similar for newer versions of KDE on 22.04. 
These are non-trivial to implement and take a significant amount of work 
to make sure that our users have what they need and want in the LTS. I 
would consider this a form of support, and while I don't believe such 
repositories should be necessary to qualify for LTS status, it should be 
noted that it's something we do. We put a lot of effort into keeping the 
LTS releases working well.

Aaron

> (I think this is very relevant to the question of LTS qualification, because
> demonstrating a track record of active maintenance of the stable release of
> a flavor goes a long way to establishing that the flavor team is delivering
> something that meets users' needs for an LTS.)
>
-- 
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20231125/18bd1783/attachment.html>