qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>, qemu-devel@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
	"David Gibson" <dgibson@redhat.com>
Subject: Re: Possible end of Ubuntu LTS 18.04 as a build target in 7.1 ?
Date: Tue, 15 Feb 2022 17:38:19 +0100	[thread overview]
Message-ID: <ca589020-564d-18d1-6526-8a624c4fe154@redhat.com> (raw)
In-Reply-To: <Yguz2GtTm+oEN0rI@redhat.com>

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



      reply	other threads:[~2022-02-15 16:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 14:08 Possible end of Ubuntu LTS 18.04 as a build target in 7.1 ? Daniel P. Berrangé
2022-02-15 16:38 ` Thomas Huth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca589020-564d-18d1-6526-8a624c4fe154@redhat.com \
    --to=thuth@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=crosa@redhat.com \
    --cc=dgibson@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=marcandre.lureau@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=samuel.thibault@ens-lyon.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).