Re: release branch policy and distributions

[Michael Hudson-Doyle <michael.hudson@canonical.com>]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

On Thu, 9 Mar 2023 at 18:27, DJ Delorie <dj@redhat.com> wrote:

> 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 :-)
>

Ah here I was talking about getting access to the machines internally :-)
Thanks for the instructions though...


> 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.
>
>