initial thoughts on backports process changes

Tue Sep 21 11:38:07 UTC 2021

[ Dan, Thomas: I'm moving you to Bcc, let's just stick with the ML that
I see you already subscribed to]

Thanks Dan for taking out the time to hash this out, saving me quite a
lot of effort.

Instead of writing my own I'll just comment inline, since I see we agree
on pretty much everything.

On Mon, Sep 20, 2021 at 06:29:08PM -0400, Dan Streetman wrote:
> 1) How the community requests backports
> 
> The existing process […] a completely unmaintainable process

+1, let's drop it.

> I suggest we restrict […]

Great, that's pretty much what I wanted, so +1 on your whole 1) point.

> 2) review of tooling, 'requestbackport' and 'backportpackage'
> 
> The 'requestbackport' script will almost certainly need to be updated,
> at best, and more likely just removed in favor of a detailed
> process/template added to the public wiki page docs.

I'd say, replace with a stub saying "this tool is deprecated, see
https://wiki...."

> I think the 'backportpackage' script will need review, and I'm
> concerned that we may have uploads generated from this tool with
> little or no actual investigation or pre-review by the requestor of
> the backport.

It all depends on what details we'll change regarding the process below.

> 3) What releases we backport to - only LTS or any/all?

This was actually a concern I had.
It's really mostly a policy decision: will we be willing to support
upgrades from LTS+backports to LTS+1?

Also, I think there might be good reasons to accept backports into
non-LTS, for example backporting debhelper just to have a newer compat
level available.

Whatever we do, we must make sure to support LTS+bpo → LTS² or (we need
to decide right away on this imho) LTS+bpo → LTS²+bpo, and not accept
anything that breaks that path.

> I'd like to suggest restricting backports to only LTS releases.

I support this stance, for now (by also saying that upgrades
LTS+bpo→LTS+1 are not supported by us).  But I'd like to revise it once
we're more set up.
Also, I'd like to talk on whether we'd be willing to concede
case-by-case exceptions like the debhelper example above.

> which would likely just add more work for no reason.

Yes, it's quite a bother to do indeed.

> 4) Security updates
> 
> On the community page, it says "When a package which has been
> backported receives a security update, the Ubuntu Backporters will
> make a best-effort attempt to update the backport" which I think we
> need to drop. I do not think our team should have any expectation at
> all of any kind of maintenance of any backport package we approve; any
> further updates to the backported package should come from the
> community, and our role should *only* be to approve or reject uploads
> to the -backports queues.

I disagree.  We should set expectations out of what we approve.
Like (throwing darts here):
 * assigning bpo-specific bugs that come to our attention to the uploader
 * stating that, unless there are good reasons, we expect that package
   to be, eventually, brought to the same version as the one in LTS²
 * I think we should also state that uploaders are very much expected to
   especially backport the security updates to that package asap (I
   mean, quicker than the above point)
The difference here, is that we are turning the responsability from the
backporters team (us) into the uploader.

> 5) Cleaning up the docs on 'Using Backports'
> 
> As this section in the wiki seems to have been written quite a while
> ago, I think it's safe to assume nobody is still running 11.10 or
> earlier. So we should be safe to clean up this section, removing all
> the reference to how to 'enable' backports. We may want to leave in
> the detail about how to change from the default 'manual install' to
> 'automatic install', but note that it's probably not a good idea to
> switch to 'automatic install' for all backports packages.

It looks like bpo suites already have
    NotAutomatic: yes
    ButAutomaticUpgrades: yes
Given that, I'd say we should drop all of that "Configuring backports".
It really is not needed and:
 a. automatically install all bpos is likely to cause problems (it
    regularly does in debian for whoever tried)
 b. that "manual install" thing is deprecated by the above mentioned
    Release headers, as apt already defaults to pin-priority=100 for
    those cases

besides that, it requires some small adjustments to the rest of the
page.

> 6) Additional restrictions on what packages are eligible
> 
> I don't see anything in the wiki docs about any "excluded" packages,
> but I think we should add some explicitly ineligible packages.

ACK.
And besides the below suggestions, I think we should just keep in mind
that section and have it grow organically all the time we think we
should start excluding cases (not necessarily "per-package").

> The obvious one is the kernel

+1 as long as HWE exists (which, IMHO, exists only because bpo didn't
work well enough in the first place).

> I also think we should restrict packages that are provided by the
> Ubuntu Cloud Archive. This list of packages probably would need to be
> defined a bit more clearly if we're going to make this a rule

I'd need to see the list of packages in there first, but if things are
as you say, then it makes sense to not have them.

> Finally, I'm very cautious about any packages that provide libraries;
> it's probably not reasonable to completely ban this, but the potential
> for breakage seems very high.

I don't necessarily agree here.  I believe that it's safe to upload
libraries as long as the actual library binary is co-installable with
the one in the base suite.

Anyway, I don't think we need to sit down and come up with an exclusion
list: it's fine to say that we are going to discuss all uploads that
looks "weird" to us, and if we decide for a no then we can add to the
list at that point.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
More about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-backports/attachments/20210921/5ab5ac71/attachment.sig>