linux-kernel - Re: [PATCH v2 0/5] 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: <023598a3-7fe5-4882-87a1-e8ec2a5f6c81@sirena.org.uk>
Date: Fri, 24 Jan 2025 17:15:03 +0000
From: Mark Brown <broonie@...nel.org>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Nikolai Kondrashov <Nikolai.Kondrashov@...hat.com>,
	Vignesh Raman <vignesh.raman@...labora.com>,
	kernelci@...ts.linux.dev, linuxtv-ci@...uxtv.org,
	dave.pigott@...labora.com, mripard@...nel.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-kselftest@...r.kernel.org, gustavo.padovan@...labora.com,
	pawiecz@...labora.com, spbnick@...il.com, tales.aparecida@...il.com,
	workflows@...r.kernel.org, skhan@...uxfoundation.org,
	kunit-dev@...glegroups.com, nfraprado@...labora.com,
	davidgow@...gle.com, cocci@...ia.fr, Julia.Lawall@...ia.fr,
	laura.nao@...labora.com, kernel@...labora.com,
	torvalds@...uxfoundation.org, gregkh@...uxfoundation.org,
	daniels@...labora.com, helen.koike@...labora.com,
	shreeya.patel@...labora.com, denys.f@...labora.com,
	nicolas.dufresne@...labora.com, louis.chauvet@...tlin.com,
	hamohammed.sa@...il.com, melissa.srw@...il.com, simona@...ll.ch,
	airlied@...il.com, Tim.Bird@...y.com,
	laurent.pinchart@...asonboard.com, leobras.c@...il.com,
	groeck@...gle.com, rdunlap@...radead.org, geert@...ux-m68k.org,
	michel.daenzer@...lbox.org, sakari.ailus@....fi
Subject: Re: [PATCH v2 0/5] kci-gitlab: Introducing GitLab-CI Pipeline for
 Kernel Testing

On Fri, Jan 24, 2025 at 06:32:07PM +0200, Jarkko Sakkinen wrote:

> Can we then agree that any CI changes can be sent untested to LKML if
> a patch set needs to reflect on those? It's not reasonable to except
> local runs Gitlab from individuals for patch sets. It makes our lives
> more difficult, not easier.

I think the theory here is that this more shared building blocks for
people who want to set something up using gitlab rather than the one
true CI system that everyone has to use.  Even with people who do end up
using gitlab there's going to be issues with things like hardware access
and just realistic resources which mean that not everyone can test
everything.  We generally have an expectation that people will make a
reasonable effort to test things, not that they're going to cover
everything, and I don't see why this should be different.

> All maintainers I know test their patches for the most part with
> BuildRoot, distro VM's and stuff like that. Not claiming that they
> don't exist, but never heard of kernel maintainer who uses Gitlab
> as their main kernel testing tool.

There's a huge diversity in what people are using for their CI
infrastructure, gitlab instances are definitely in there already.  The
last time I looked at the implementation the clang testing was driven
through gitlab, AIUI the DRM and media systems also have something.  One
of the ways gitlab is handy is that it's something that companies are
likely to have set up anyway which helps with getting things
provisioned.

> > Sure, a script could be contributed too, but the value of this contribution is
> > a ready-made integration. And we want to make it easily discoverable, and
> > easily contributed to.

> This is definitely NOT "lots of flexibility".

> Are you dead seriously claiming that DevOps engineers could not handle
> well defined CI scripts and bind to whatever CI makes sense to them?
> o_O

There's going to be an audience out there for people who aren't
specifically devops people and would find it helpful to have something
to look at when getting started, and even where people are capable of
doing the work it seems helpful to pool effort on the more common stuff.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)