Re: release branch policy and distributions

[DJ Delorie <dj@redhat.com>]

Michael Hudson-Doyle via Libc-alpha <libc-alpha@sourceware.org> writes:
> I think running the glibc testsuite on a wider range of hardware would be
> the most significant thing we could do here. We do have quite a range of
> hardware for testing but I wouldn't know where to start about using it for
> glibc pre-commit CI,

Fortunately, I do :-)

The code is here: https://gitlab.com/djdelorie/glibc-cicd

The URL for your runner to track is: https://delorie.com/cicd/curator.cgi
(unless you want to run your own curator, but there's no need)

You'll need to create an API token in our patchwork instance if you want
to report results.

In general, your runner will inspect the event and decide what
testing[*], if any, your organization wants to do.  It will then queue a
task that your trybots will dequeue and run.  You organize queues based
on hardware types or pools or whatever, so for example you could have
some expensive-to-use AVX512 machine only run tests when the patch
mentions AVX512, or a raspberry pi pool that tests patches that touch
sysdeps/arm, etc.


[*] it doesn't have to be testing, it could be anything - like spell
checking patches to documentation, or checking coding standards, etc.
Even grepping for interesting new sandwich recipes, although I hope you
don't find any in glibc.