[Pkg-xen-devel] Xen 4.14 for Bullseye, and consequences for security support (was: Re: On uploading a new xen to unstable)

[Hans van Kranenburg]

Hi all,

On 2/2/21 8:53 PM, Maximilian Engelhardt wrote:
> 
> I just wanted to ask what are your plans for uploading a new version of xen to 
> unstable as the soft freeze is starting pretty soon at 2021-02-12.

We will stay on Xen 4.14 for Debian Bullseye.

I will clean up and forward WIP packaging changes on top of latest
upstream 4.14-stable and upload the result RSN (tm). There's not much
happening in the Debian BTS so far, so either there are no problems, or
no one is testing anything before it's too late.

The Xen Project has a cadence of doing a release every 8 months. Debian
currently releases every two years. Like during the Buster freeze, those
freeze and release moments coincide quite heavily. (3 times 8 months is
also two years...).

There have been thoughts and discussions about trying to get Xen 4.15
into Bullseye. The single most interesting reason why would be to have
an end-of-security support for Xen that better matches the EOL of Bullseye.

In the end I chose to not try to get that done. There are various
reasons for this (just typing them while thinking out loud):
* We had the same issue for Buster (Xen 4.11 or 4.12-RC?).
* We have the same issue now.
* We probably will have the same issue for Bullseye+1.
* So, I see a pattern, and compensating for this with more Debian Xen
Team effort and painful situations for users is not a sustainable solution.
* For this year, Ian is also Release Manager for the upstream Xen 4.15
release, and this is already eating away all of his work-time. That
means, less availability to help review changes and spend time to act as
mentor for me in the Debian context.
* Personally I really have too much stuff going on in my work- and
personal life at the moment. When spring happens, for my personal
health, I need to be outside, working in the garden or fixing the old
timer '72 Citroen Dyane, instead of being inside at the computer having
to deal with user complaints, while the sun is shining in the weekend.
* We can't present users who put effort in testing upgrades for their
Xen setup during the Debian freeze with a Xen package that is not even
an RC-1 yet.

So, what consequences does this have?

Debian Buster Release: 2019-07
Debian Buster EOL: ~2022-07
Xen 4.11 Initial-Release: 2018-07-10
Xen 4.11 Security-Support-Until: 2021-07-10

Debian Bullseye Release: ~2021-04
Debian Bullseye EOL: ~2024-04
Xen 4.14 Initial-Release: 2020-07-24
Xen 4.14 Security-Support-Until: 2023-07-24

Debian Bookworm Release: ~2023-04 ?! ~2023-07 ?!

Anyway, you see the pattern. So, if you use Xen, you better start
preparing right now to upgrade everything. As Debian Xen Team, we will
stop providing security updates for Debian as soon as upstream stops
providing them. And, because Bullseye seems to get a record fast freeze
happening, there's still 3 months to upgrade after the release. Next
time it might be even worse. .oO(ooh, backports?)

Unless either Debian or the Xen Project changes release schedules, we
have to tell our users that:
* It's ok to start testing at or already before early Debian freeze
times. This is the time to report any problem you encounter, because we
still have the possibility to do bug fixes.
* At the day of the next Debian release happening, you should already be
well prepared to apply the changes to your production systems, and only
be left with the task to actually apply them, and then do it.

> I also added a note to your last commit in knorrie/sid ("d/control: allow ovn-
> host besides bridge-utils"), you might want to have a look if you haven't seen 
> it yet.

I have seen it, thanks!, I simply visually missed this while looking at
the overview page of it on packages.debian.org. I will take out that change.

Hans

P.S. To make it possible to have Xen packages in Debian backports, so
that you can e.g. run Bullseye with newer Xen because you just bought
the newest hardware, or because you need more time to upgrade to
Bullseye+1, first qemu needs to be changed to not depend on a specific
Xen version. There has been research going on about this topic (search
for: RFC: qemu and Xen ABI-unstable libs on the xen development list),
but the actual work did just not happen yet. So, Bullseye will not have
Xen in bullseye-backports.

You can of course build all of the stuff with dependencies yourself
anyway if you want it or need it, but we can't provide it in Debian itself.