Proposal: sunset the backports pockets

[Jeffrey Lane]

Excellent. Thank you for that detailed response Robie!

On Mon, Jul 19, 2021 at 1:00 PM Robie Basak <robie.basak at 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."