On Sat, Oct 30, 2021 at 3:57 PM Mattia Rizzolo <[email protected]> wrote: > > Hi! > > So, whilst I filed RT#37048 for the wiki.u.c/UbuntuBackports page that > is misbehaving, I copied the page under /WIP and I'm doing some > changes. > > https://wiki.ubuntu.com/UbuntuBackports/WIP > > I'm dropping here some notes concerning those changes, so that you may > (or may not) comment on them. > > * moved "Responsibilities of the Backporter" to the top > Really that's probably the biggest change compared to before, and > (also in debian) I know it's going to be selectively ignored by > contributors. So I'd like to highlight it.
+1 > * In the testing point, I dropped this: > This testing should cover as much of the package functionality as > possible, not just any missing functionality or feature that you > are requesting the backport for. > The reason being that doing that it's a *huge* burden. It totally > doesn't feel so while writing, and it could even be considered the > proper thing to do. But I'm sure not even us 3 would ever bother > doing that. Imagine having to test every single devscripts and > ubuntu-dev-tools script for all releases I'm going to backport the > package in. Or having to test as many entry points of a library > package. That's just not going to happen, so let's not lie on the > process page either. +1, I totally agree there are some processes with "requirements" that are effectively ignored most of the time - and you're right that testing *everything* in a backported package is unreasonable and unlikely. So any manual testing would likely be up to the backport requestor, to verify their specific need and/or whatever cursory manual tests they want to run. We should state that any existing automated tests should be run though, right? Specifically, any build-time tests, and any autopkgtests? > * in "Continued Functionality of Reverse-Dependencies": it's not > feasible to say that a backported package must always work with any > possible rev-dep. There are plenty of cases when that's not even > wanted. That's fine IMHO. I changed the requirement to a "should" > (from a "must") and added a sentence saying that if that's not > possible the package needs to carry a Breaks, etc. +1 definitely > * I tried to replace "the person requesting the backport" to "the > backporter", as that's more correct with the new procedure, since > that person is not "requesting" only anymore, they are actually doing > the work. +1 > * Also clarified that the backporter is responsable for bugs that are > specific of the backported version of the package. +1 > * I added quite a bunch of words about the package versioning +1, but i sure wish there was some coordinated location for the 'strategy' of how to set version numbers between devel, sru, bpo, security, etc... > * "and/or if you are unfamiliar with preparing packages for upload" - > I'm not dropping that, but honestly, if we have such people in our > ACLs I'd feel much more comfortable if we had their rights revoked… +1 yep, no need for that added text - anyone with ACL absolutely should know how to prepare things. > * you wrote "This policy specifically means that backports are allowed > for interim (non-LTS) releases, but are not required.", but I thought > we agreed that we do not *want* backports in non-LTS expect for > special cases. I rewrote it accordingly. +1 > * I added that "special cases" section I already sent to this ML earlier > in the month. +1 for this, however I'd suggest we use a term other than 'blacklist'; maybe 'denylist' or 'disallowed' > > > Honestly, if you get me the green light I'd like to start by doing those > "tools uploads" next week (for you to review then :P) > > -- > 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 -- ubuntu-backports mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
