Revisions to the Backports process

[Dan Streetman]

On Sat, Oct 30, 2021 at 3:57 PM Mattia Rizzolo <mapreri at ubuntu.com> 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
> ubuntu-backports at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports