On Tue, Sep 21, 2021 at 7:38 AM Mattia Rizzolo <[email protected]> wrote: > > [ 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.
that's a valid point, as the example of debhelper certainly could be argued to be useful to backport to non-LTS by itself. on a side note, I keep a ppa of daily builds of upstream debhelper for just that reason: https://launchpad.net/~ubuntu-support-team/+archive/ubuntu/debhelper I'm not suggesting that we do something like that with backports, nor does it replace the usefulness of having a backported debhelper in -backports, but it certainly could be useful if key packages, like debhelper, were available in -backports across LTS and non-LTS releases. > > 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. +1 > > > 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. +1 on case-by-case exceptions, and also agreed that we'll likely need to discuss this more in the future (and we can at the mtg as well) > > > 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. +1 agreed, I think your last line here summarizes it well > > > 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"). +1 > > > 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. my understanding is that the exact, specific list for any particular UCA release is essentially "as needed", so this might be better as a "loose" restriction, or simply a check that's part of a pre-upload tool/script, like backportpackage for reference, the ppas where they are built are here https://launchpad.net/~ubuntu-cloud-archive and the official archive, which you can add with 'add-apt-repository cloud-archive:RELEASENAME' http://ubuntu-cloud.archive.canonical.com/ > > > 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. +1 > > > -- > 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 `- -- ubuntu-backports mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
