All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Thomas Huth <thuth@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Kevin Wolf" <kwolf@redhat.com>, "John Snow" <jsnow@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: no more pullreq processing til February
Date: Thu, 26 Jan 2023 20:49:15 +0000	[thread overview]
Message-ID: <874jsdow4k.fsf@linaro.org> (raw)
In-Reply-To: <088a1c95-5332-d120-8917-1aa52c929da9@redhat.com>


Thomas Huth <thuth@redhat.com> writes:

> On 26/01/2023 15.41, Peter Maydell wrote:
>> On Thu, 26 Jan 2023 at 14:35, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>> I'm confident we can rationalize our jobs, especially the cross
>>> compilation ones.
>>>
>>> For each non-x86 arch we've got two sets of jobs, one for system
>>> emulators and one for user emulators.
>>>
>>> IMHO the most interesting part of non-x86 testing is the TCG
>>> host target. We don't need 2 jobs to cover that, either system
>>> or user emulators would cover TCG build / test. Most of the rest
>>> of code is not heavily host arch dependant.
>> I'm not super enthusiastic about cutting this down.
>> I find the non-x86 testing is the most interesting part
>> of the CI -- most patch submitters and system submaintainers
>> have already done local compile-and-build with the common
>> x86_64 recent-distro target, so those parts pretty much
>> always succeed. The benefit of the auto CI is in keeping
>> the platforms that aren't so widely used by developers
>> working (both different-host-arch and different-OS).
>
> I mostly agree. Question is whether we really need all of them, e.g.
> do we really need both, the *-armel and the *-armhf jobs for both, the
> -user and the -system part? Or would it be still ok to e.g. only have
> a -armel-user and a -armhf-system job and drop the other two?

I suspect just the armhf target is good enough but as you say later...

> I think there are also other possibilities where we could cut down CI
> minutes, e.g.:
>
> - Avoid that some of the -softmmu targets get build multiple
>   times
>
> - Re-arrange the Avocodo jobs: We should maybe rather sort them
>   by target system instead of host distro to avoid that some
>   targets get tested twice here.

We can use tags to select groups of avocado tests I think.

> - Do we really need Linux-based clang jobs if we test Clang
>   compilation with macOS and FreeBSD, too?

Depends - is there any version drift between them?

> - Would it be OK to merge the merge the build-without-default-
>   devices and build-without-default-features jobs?

Sure

>
> And after all, I'd like to raise one question again: Could we finally
> stop supporting 32-bit hosts? ... that would really help to get rid of
> both, some CI minutes and some maintainer burden.

I'm totally down for that. Most distros have put 32 bit onto life
support haven't they?


>
>  Thomas


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro


  reply	other threads:[~2023-01-26 20:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 13:22 no more pullreq processing til February Peter Maydell
2023-01-26 13:52 ` Eldon Stegall
2023-01-26 14:13   ` Alex Bennée
2023-01-26 14:27     ` Peter Maydell
2023-01-26 14:38     ` Daniel P. Berrangé
2023-01-26 18:41       ` Eldon Stegall
2023-01-27  9:53         ` Daniel P. Berrangé
2023-01-26 14:18   ` Daniel P. Berrangé
2023-01-26 14:30     ` Daniel P. Berrangé
2023-01-27  8:50       ` Gerd Hoffmann
2023-01-26 13:57 ` Alex Bennée
2023-01-26 14:07   ` Daniel Henrique Barboza
2023-01-26 14:27     ` Daniel P. Berrangé
2023-01-26 14:35   ` Daniel P. Berrangé
2023-01-26 14:41     ` Peter Maydell
2023-01-26 18:17       ` Thomas Huth
2023-01-26 20:49         ` Alex Bennée [this message]
2023-01-26 14:25 ` Stefan Hajnoczi
2023-01-26 14:28   ` Peter Maydell
2023-01-27  7:36     ` Thomas Huth
2023-01-27 12:39     ` Kevin Wolf
2023-01-27 12:47       ` Daniel P. Berrangé
2023-01-27 13:11       ` Peter Maydell
2023-01-27 13:12         ` Peter Maydell
2023-02-01 16:18       ` Peter Maydell
2023-01-27  9:30 ` Markus Armbruster

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=874jsdow4k.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.