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
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel