Proposal: sunset the backports pockets

[Robie Basak]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20210719/63a06b03/attachment-0001.sig>