Possible end of Ubuntu LTS 18.04 as a build target in 7.1 ?

Possible end of Ubuntu LTS 18.04 as a build target in 7.1 ?

[Daniel P. Berrangé]

Per our platform support policy

  https://www.qemu.org/docs/master/about/build-platforms.html

  "The project aims to support the most recent major version at all
   times. Support for the previous major version will be dropped 2
   years after the new major version is released or when the vendor
   itself drops support, whichever comes first."

In April this year, Ubuntu LTS 22.04 will arrive, which means the
"previous" release will then be considered to be "LTS 20.04" and
thus "18.04" will no longer be in scope for what we aim to support.

It is possible that this might enable us to assume newer versions
of some software we depend on, but I've not analysed the situation
yet. This would apply from start of 7.1 development cycle if any
min version bumps do appear relevant.

When we previously had 16.04 fall out of scope for support, we had
a roadblock in bumping min versions. IIRC this was due to various
machines in the compile farm Peter used for merge testing not
supporting anything newer.

I don't have a good understanding of what machines are used for
testing now, so I'm wondering if we're going to hit any kind of
similar issue if we try to drop 18.04 support ?  If so we might
want to start thinking about our options now.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Possible end of Ubuntu LTS 18.04 as a build target in 7.1 ?

[Thomas Huth]

On 15/02/2022 15.08, Daniel P. Berrangé wrote:
> Per our platform support policy
> 
>    https://www.qemu.org/docs/master/about/build-platforms.html
> 
>    "The project aims to support the most recent major version at all
>     times. Support for the previous major version will be dropped 2
>     years after the new major version is released or when the vendor
>     itself drops support, whichever comes first."
> 
> In April this year, Ubuntu LTS 22.04 will arrive, which means the
> "previous" release will then be considered to be "LTS 20.04" and
> thus "18.04" will no longer be in scope for what we aim to support.
> 
> It is possible that this might enable us to assume newer versions
> of some software we depend on, but I've not analysed the situation
> yet. This would apply from start of 7.1 development cycle if any
> min version bumps do appear relevant.

What I really would like to see: Could we get rid of some of the git 
submodules, since they keep being a pain from time to time. Could we get rid 
of the capstone submodule? libslirp? dtc? ... but this needs some careful 
checking first, of course.

> When we previously had 16.04 fall out of scope for support, we had
> a roadblock in bumping min versions. IIRC this was due to various
> machines in the compile farm Peter used for merge testing not
> supporting anything newer.
> 
> I don't have a good understanding of what machines are used for
> testing now, so I'm wondering if we're going to hit any kind of
> similar issue if we try to drop 18.04 support ?  If so we might
> want to start thinking about our options now.

I think the most difficult part are maybe the custom runners in 
.gitlab-ci.d/custom-runners/ubuntu-18.04-s390x.yml ... who has access to 
that system and could try to get these updated?

We've got some more few occurances, e.g. in .gitlab-ci.d/opensbi/Dockerfile 
and in .gitlab-ci.d/containers.yml ... but that can be done by anybody who 
knows how to use the gitlab-CI.

And there are still some jobs on bionic in .travis.yml - but I can take care 
of those.

  Thomas