From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"John Snow" <jsnow@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Claudio Fontana" <cfontana@suse.de>
Subject: Re: [RFC PATCH] docs/about/build-platforms: Refine the distro support policy
Date: Mon, 20 Feb 2023 10:26:33 +0100 [thread overview]
Message-ID: <87cz64znzq.fsf@pond.sub.org> (raw)
In-Reply-To: <CABgObfYetmCBVQcVv4vwJKjPmum5ZFJ0dr2HkN9yRtR_8NHSuw@mail.gmail.com> (Paolo Bonzini's message of "Fri, 17 Feb 2023 21:17:21 +0100")
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il ven 17 feb 2023, 19:47 Thomas Huth <thuth@redhat.com> ha scritto:
>
>> On 17/02/2023 16.59, Daniel P. Berrangé wrote:
>> > On Fri, Feb 17, 2023 at 04:55:49PM +0100, Markus Armbruster wrote:
>> ....
>> > The cost/benefit tradeoff of dropping the platforms entirely
>> > is not obviously favourable when we don't have clear demand
>> > to bump the min versions of native packages, and the cost to
>> > users stuck on these platforms to build their own toolchain
>> > or libraries is very high.
>>
>> There's another urgent point which I completely forget to mention in my
>> patch description (not sure how I managed that, since it's bugging me
>> quite
>> badly in the past weeks): We're struggling heavily with CI minutes.
>
>
> The only viable solution for CI minutes is going to be private runners,
> it's not easy to cut 30% of the jobs.
>
> We're using less than half of our Azure sponsorship budget, and could also
> find other sources; either Azure Kubernetes or AWS Fargate are pretty cheap
> for running CI because unlike VM instances you pay for just the time that
> CI is running (at least with Azure you still have VMs but they scale out
> dynamically).
To anyone arguing for support of yet another host architecture / target
architecture / configuration / whatever: sponsoring its CI would
demonstrate seriousness :)
> The complicated part is setting up the kubernetes executor for
> gitlab-runner, but we'll find someone. :)
next prev parent reply other threads:[~2023-02-20 9:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 13:26 [RFC PATCH] docs/about/build-platforms: Refine the distro support policy Thomas Huth
2023-02-17 14:44 ` Paolo Bonzini
2023-02-17 14:59 ` Daniel P. Berrangé
2023-02-17 15:06 ` Daniel P. Berrangé
2023-02-17 18:30 ` Thomas Huth
2023-02-20 9:21 ` Markus Armbruster
2023-02-17 15:55 ` Markus Armbruster
2023-02-17 15:59 ` Daniel P. Berrangé
2023-02-17 18:47 ` Thomas Huth
2023-02-17 20:17 ` Paolo Bonzini
2023-02-20 9:26 ` Markus Armbruster [this message]
2023-02-20 9:39 ` Daniel P. Berrangé
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=87cz64znzq.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=cfontana@suse.de \
--cc=jsnow@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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.