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 -- ubuntu-backports mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
