Excellent. Thank you for that detailed response Robie! On Mon, Jul 19, 2021 at 1:00 PM Robie Basak <robie.ba...@ubuntu.com> wrote: > > On Mon, Jul 19, 2021 at 10:17:44AM -0400, Jeffrey Lane wrote: > > Would it be worthwhile, (or possible) to keep it open quietly for > > special cases? > > We can certainly leave ourselves open for the backports process to > restart if someone steps up and adapts it into something workable. > Similarly, I'm sure the occasional exception will be fine, with the > caveat that I don't want publication to the backports pocket to > effectively only be available to privileged people as I mentioned in > another subthread. > > > Or perhaps amend the SRU process to incorporate bits > > of Backports? > > The key difference between the updates and backports pockets is that > users have to explicitly opt-in to backports, whereas the updates > pockets is recommended to all users. Therefore, the general user > expectation is that the updates pocket will not change behaviour from a > user's perpsective. There are exceptions, but that's the general rule. > So I'm not keen on stretching the SRU process to accommodate backports > in the general case, unless the updates already qualify under the > existing SRU policy anyway. However, other alternatives to the backports > pocket already exist. > > For apps, we have snaps, which have the advantage of third party > developers being able to publish directly and safely, without manual > review being required. The problem we have with manual review shortages > doesn't exist with snaps. > > For everything else, third party PPAs are still possible - they have > their own problems, but apart from an "official" stamp / trust anchor, > and therefore requiring a more explicit opt-in on a per-PPA basis, they > are exactly functionally equivalent to the backports pocket. An official > stamp for any kind of deb-based publishing necessarily requires manual > review. "Official" manual review is exactly the problem we're facing, > and it's the only property we'd lose if a backport went into a PPA > instead of the backports pocket. So either we figure out how to deal > with the manual review problem, or we lose nothing in sunsetting > backports. > > Admittedly there's a nuance here which is that putting an official stamp > on things but with a more relaxed review might also be acceptable, > because that helps draw attention and fix problems by providing a common > coordination point. So that's possible too, and I have said I support, > in principle, keeping the backports pocket open if somebody wants to > drive such a change. But, to date, we have no volunteers for that, so > that's why I think it's time to sunset it now, rather than delaying > further for reform that experience shows us won't come. > > > Specifically, I'm thinking of cases like this bug I've been working on: > > > > https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1903204 > > As we discussed privately, I think this bug qualifies for an SRU under > our "hardware enablement" exception, and I recommend doing that in this > case. > > HTH! > > Robie
-- Jeff Lane Engineering Manager IHV/OEM Alliances and Server Certification "Entropy isn't what it used to be." -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
