linux-kernel - Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wiccniE=iZDC_e7T+J8iPVQbh1Wi5BaVee9COfy+ZaYKg@mail.gmail.com>
Date: Fri, 1 Mar 2024 12:10:35 -0800
From: Linus Torvalds <torvalds@...uxfoundation.org>
To: Nikolai Kondrashov <spbnick@...il.com>
Cc: Maxime Ripard <mripard@...nel.org>, Helen Koike <helen.koike@...labora.com>, 
	linuxtv-ci@...uxtv.org, dave.pigott@...labora.com, 
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	linux-kselftest@...r.kernel.org, gustavo.padovan@...labora.com, 
	pawiecz@...labora.com, tales.aparecida@...il.com, workflows@...r.kernel.org, 
	kernelci@...ts.linux.dev, skhan@...uxfoundation.org, 
	kunit-dev@...glegroups.com, nfraprado@...labora.com, davidgow@...gle.com, 
	cocci@...ia.fr, Julia.Lawall@...ia.fr, laura.nao@...labora.com, 
	ricardo.canuelo@...labora.com, kernel@...labora.com, 
	gregkh@...uxfoundation.org
Subject: Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov <spbnick@...il.com> wrote:
>
> I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
> should be done. Still, we would like to help people, who are interested in
> this kind of thing, to set it up. How about we reframe this contribution as a
> sort of template, or a reference for people to start their setup with,
> assuming that most maintainers would want to tweak it? We would also be glad
> to stand by for questions and help, as people try to use it.

Ack. I think seeing it as a library for various gitlab CI models would
be a lot more palatable. Particularly if you can then show that yes,
it is also relevant to our currently existing drm case.

So I'm not objecting to having (for example) some kind of CI helper
templates - I think a logical place would be in tools/ci/ which is
kind of alongside our tools/testing subdirectory.

(And then perhaps have a 'gitlab' directory under that. I'm not sure
whether - and how much - commonality there might be between the
different CI models of different hosts).

Just to clarify: when I say "a logical place", I very much want to
emphasize the "a" - maybe there are better places, and I'm not saying
that is the only possible place. But it sounds more logical to me than
some.

            Linus