Merge ~bryce/+git/server-backports:update-to-lunar into ~canonical-server/+git/server-backports:main

Proposed by Bryce Harrington
Status: Needs review
Proposed branch: ~bryce/+git/server-backports:update-to-lunar
Merge into: ~canonical-server/+git/server-backports:main
Diff against target: 490 lines (+273/-61)
17 files modified
Readme.md (+162/-39)
backports.json (+77/-0)
recipes/dpdk-jammy.recipe (+3/-0)
recipes/edk2-jammy.recipe (+2/-2)
recipes/libslirp-jammy.recipe (+2/-2)
recipes/libvirt-jammy.recipe (+2/-2)
recipes/libvirt-python-jammy.recipe (+2/-2)
recipes/meson-jammy.recipe (+3/-0)
recipes/openvswitch-jammy.recipe (+2/-2)
recipes/qemu-jammy.recipe (+2/-2)
recipes/rdma-core-jammy.recipe (+2/-2)
recipes/seabios-jammy.recipe (+2/-2)
recipes/spice-jammy.recipe (+2/-2)
recipes/spice-protocol-jammy.recipe (+3/-0)
recipes/spice-vdagent-jammy.recipe (+2/-2)
recipes/virglrenderer-jammy.recipe (+3/-0)
recipes/virt-manager-jammy.recipe (+2/-2)
Reviewer Review Type Date Requested Status
Christian Ehrhardt  Needs Fixing
Review via email: mp+452488@code.staging.launchpad.net

This proposal supersedes a proposal from 2023-08-26.

Description of the change

I've completed the backport from lunar to jammy (I think - please doublecheck!) This branch MP includes both the backport recipe updates themselves, and the updates I did to the Readme to both clarify the process I used and parameterize it a bit. Hopefully having this all in a unified MP will lend itself to easier review than split apart.

I got hung up a bit on the presence or absence of branches seemingly at random, until it was pointed out the missing ones were intentionally missing since they had no backport changes. I've attempted to call this out so it hopefully won't be a point of confusion for others in the future. Otherwise, the longer this PPA is maintained and the more branches come and go, the less obvious the state of the repository will be.

Another point of confusion came from the specified release codenames, since from one cycle to the next a release that was backported *from* will become one that is backported *to*. I've replaced those codenames with variables which both parameterizes the command lines and also gives them a name that communicates what they represent.

Another motivation to parameterize the examples was to make the document closer to paint-by-numbers style, which can help reproducibility and reduction of errors. Obviously, this also makes a firm step towards scripting some or all of the process, but I don't think I'm ready to take that step yet since there's still idiosyncrasies and thoughtful attention needed to spot and fix errors.

I've also introduced a `backports.json` file as discussed for capturing notes about each of the packages. I went with JSON since it is tool-friendly, and has a strongly typed data structure that should be non-ambiguous in how to maintain and extend it later. That said, consider both the format and structure to still be provisional, and may evolve as more data needs included and/or tools start making direct use of it.

To post a comment you must log in.
Revision history for this message
Christian Ehrhardt  (paelzer) wrote : Posted in a previous version of this proposal

Thanks for starting on it and reaching out Bryce.
There are a lot of questions and answers, I hope they help.
But please catch me in the little bit our workdays overlap so I can answer anything left open more directly.

---

Oh, and one more detail I hopefully have mentioned, but I'm not sure.
Due to the LTS cycles, the pain the more backports get distance and the fact that Bionic entered extended support.

Already last time Bionic backports got "stuck" on Jammy and they will stay on that.
No need to bump them to Lunar, but helpful to the users to keep them around on Jammy as-is.
AFAICS you have already done that right, but I wanted to be sure.

---

Also I have a feeling what threw you off, the naming of the branches and then using a shorter name in the recipes. See the comments below, if that was it - we might just change it as part of this times update.

---

BTW, since we have been getting so late into the cycle with this we can almost do the same again in just a bit (for the mantic based backports). So maybe already in November you can be executing the new code and documentation again.
That should help to ensure we really managed to understand and document it well this time :-)

Revision history for this message
Bryce Harrington (bryce) wrote : Posted in a previous version of this proposal

Thanks for getting back on this, I think those answers will help. Further comments below.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I like the json, that will help passing this task between developers and tooling.
In a future version "notes" could be a list and that list could go into the changelog we generate.

One question on that json file though, does this need to be per-target-release?
If so, should we do that now or next time (fine with me, but add a TODO: somewhere).

---

I've left a comment for an edge case that - now that it is more paint-by-numbers - has the risk to be missed or surprise someone.
That is a minimal extra paragraph for the readme.

---

And then there is the overall scope.
We have - and sorry if that wasn't clear in the readme - the intent to:
- provide these for Ubuntu LTS releases
- update them following up to next-next-LTS

At this point the tradeoff of backport effort vs gain is diminishing.

Due to that bionic is intentionally stuck on backports from Jammy.
But Focal would continue to move until it is based on 24.04 NN.
And AFAICS so far this only includes the builds for Jammy.
So the Focal builds should be updated as well and probably the documentation aspect that made you miss it.

review: Needs Fixing

There was an error fetching revisions from git servers. Please try again in a few minutes. If the problem persists, contact Launchpad support.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches