Proposal: sunset the backports pockets
Bryce Harrington
bryce.harrington at canonical.com
Mon Jul 19 19:50:06 UTC 2021
On Mon, Jul 19, 2021 at 11:25:48AM -0700, Erich Eickmeyer wrote:
> So, yes, I will block a so-called "improvement" when it comes down to quitting
> vs exhausting all other options, because, in my opinion, quitting is not an
> option.
Totally get what you're saying Erich, and exactly right that users need
avenues for getting formally backported software on Ubuntu. This is a
situation I've found myself in on both sides: as an upstream maintainer
wanting to get new releases out to LTS users, and as a distro developer
handling ubuntu-backports requests. You're right that the bottleneck in
the process is a huge hinderance. There are other fundamental
challenges to it, such as backporting applications that need updated
dependencies too (which is not at all uncommon).
And I get what you're saying about throwing babies out with bathwater
and the desire to "never give up".
But I'd point out the Big-Picture Goal here is getting properly vetted
software backports out to users. For that, there are *many* options
(snaps, PPAs, SRU process refinements, docker, et al) that have come
about since the initial introduction of -backports. There are pros/cons
to these, of course, but at a system level I'd argue that these other
options may be why demand for (and interest in maintaining)
ubuntu-backports dried up. The other options solve problems -backports
can't, or are more convenient or more flexible.
So, I would suggest viewing this not as "quitting" but rather a
recognization that ubuntu-backports hasn't worked as a process, and that
letting it go will open space for other ideas to thrive. We may be
better off to invest our limited time and attention by contributing to
the backporting processes that are already attracting volunteer
attention.
Bryce
More information about the ubuntu-devel
mailing list