clarification on specific wording for no-bug-required backport exceptions

[Dan Streetman]

Pinging this again, with follow up to try to push this through.

I propose that we allow backports with no associated bug if all these
conditions are met:

1) The package has already been accepted into the backports pocket for
the target, or older (still supported), LTS release. In order to avoid
requiring a bug to backport to each new release, a backport into an
older LTS release satisfies this for a newer release; e.g. a package
already in backports for 22.04 satisfies this requirement to backport
into 24.04 (and 24.10 if the package already has a non-LTS backport
exception) once it is released.
2) The backport contains no code changes; the only change is a new
backport entry in the changelog. The Backports Team reviewer may waive
this requirement if they feel any changes are minor.
3) The Backports Team reviewer has no concerns or questions after
reviewing the backport. The reviewer may, for any reason, reject the
backport and request a reupload with a bug.

If we limit the no-bug backports to just that criteria, then it's
pretty easy to check items #1 and #2 during review, and approve the
upload if everything looks good (which is usually the case for the few
packages we regularly see backported, at least so far).

This would also require new backports to always open a bug for at
least the first backport.

Any thoughts? Let's try to come to some agreement on this at the first
2024 meeting.


On Sun, Feb 6, 2022 at 7:43 PM Daniel Streetman <ddstreet at ieee.org> wrote:
>
> This is to start/continue the discussion from the last meeting, to get clear wording on what backports the team will accept without a corresponding bug.
>
> For reference, discussion was started at the last mtg:
> https://irclogs.ubuntu.com/2022/01/26/%23ubuntu-meeting.html
>
> My first thought is no-bug backports should have no code changes at all from the later release (i.e. only the change in package version to add the BPO suffix). Maybe that's too restrictive though?