From: Eldon Stegall <eldon-qemu@eldondev.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Kevin Wolf" <kwolf@redhat.com>, "John Snow" <jsnow@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: no more pullreq processing til February
Date: Thu, 26 Jan 2023 13:52:39 +0000 [thread overview]
Message-ID: <Y9KFp06pp/qohgV1@invalid> (raw)
In-Reply-To: <CAFEAcA8v8hrqkFemdT5x_O5_mdps4wpdRCoVAfts+oVJj_qTVw@mail.gmail.com>
On Thu, Jan 26, 2023 at 01:22:32PM +0000, Peter Maydell wrote:
> Hi; we've run out of gitlab CI pipeline minutes for this month.
> This leaves us the choice of:
> (a) don't process any more pullreqs til we get more minutes in Feb
> (b) merge pullreqs blindly without CI testing
> (c) buy more minutes
>
> For the moment I propose to take option (a). My mail filter will
> continue to track pullreqs that get sent to the list, but I won't
> do anything with them.
>
> If anybody has a better suggestion feel free :-)
Would it be possible if (d) were to run self-hosted instances of the
runner? I am not sure how gitlab pricing works, but I believe on github
self-hosted runners are free.
I have several baremetal machines colocated that I could dedicate to
execute these runs, dual processor xeons with a couple hundred gigs of
RAM. I would need approx 48 hours notice to initially provision the
machines. I would be happy to provide root credentials and work out IPMI
access if that becomes necessary.
If this offering isn't suitable, let me know how we can consider
adapting something to the project's needs.
Thanks,
Eldon
next prev parent reply other threads:[~2023-01-26 13:53 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 [this message]
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
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=Y9KFp06pp/qohgV1@invalid \
--to=eldon-qemu@eldondev.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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).