+Stefan for overall project resources.

On 10/3/22 12:07, Daniel P. Berrangé wrote:
On Thu, Mar 10, 2022 at 12:00:35PM +0100, Christian Schoenebeck wrote:
On Mittwoch, 9. März 2022 12:44:16 CET Daniel P. Berrangé wrote:
On Wed, Mar 09, 2022 at 11:40:42AM +0100, Christian Schoenebeck wrote:
On Mittwoch, 9. März 2022 11:05:02 CET Philippe Mathieu-Daudé wrote:
Not sure what you have in mind. I'm totally new to the macOS/Darwin
world, and have no choice but to use it as primary workstation and
for CI builds, so I can help with overall testing / maintenance.

Peter, since you take some macOS patches, would you like to maintain
this officially? Since I doubt you want to take yet another
responsibility, what about having a co-maintained section, including
technical expertise from Akihiko / Joelle / Christian? (Cc'ed)

Regards,

Also CCing Cameron on this, just in case someone at Apple could spend some
slices on QEMU macOS patches in general as well.

As for my part: I try to help out more on the macOS front. As there's now
macOS host support for 9p I have to start QEMU testing on macOS locally
anyway. Too bad that macOS CI tests on Github are no longer available BTW.

Note QEMU gets macOS CI coverage in GitLab. We use a clever trick by
which we use 'cirrus-run' from the GitLab job to trigger a build in
Cirrus CI's macOS builders, and pull the results back when its done.

Any contributor can get this working on their QEMU fork too, if they
configure the needed Cirrus CI API token. See the docs in

    .gitlab-ci.d/cirrus/README.rst

This is enough for build + automated tests.

Does this mean that people no longer have to pull their credit card just for
running CI tests on Gitlab?

Not really. The CC validation is something GitLab have had to force
onto all new accounts due to cryptominer abuse of their free shared
CI runners :-( If you have VMs somewhere you could theoretically
spin up your own CI runners instead of using the shared runners and
that could avoid the CC validation need.

Not that trivial, first you need to figure out the list of dependencies
GitLab images come with, then you realize you need 50GiB+ of available
storage a single pipeline (due to all the Docker images pulled / built)
and you also need a decent internet link otherwise various jobs timeout
randomly, then you have to wait 20h+ with a quad-core CPU / 16GiB RAM,
and eventually you realize you lost 3 days of your life to not register
your CC which you'll be forced to give anyway.

Long term maintainers don't realize that because they had the luxury to
open their GitLab account soon enough and are now privileged.

It is unfortunate the project strongly suggest new maintainers to pass
by that hassle and doesn't provide access to project resources instead.

But then I know, while the project has access to FOSS hardware resources
it doesn't have human resources to maintain them so can't use them, back
to square one.

Regards,

Phil.

Reply via email to