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

[Maxime Ripard]

On Sat, Mar 02, 2024 at 02:10:51PM -0800, Guenter Roeck wrote:
> On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov <spbnick@xxxxxxxxx> wrote:
> > >
> > > However, I think a better approach would be *not* to add the .gitlab-ci.yaml
> > > file in the root of the source tree, but instead change the very same repo
> > > setting to point to a particular entry YAML, *inside* the repo (somewhere
> > > under "ci" directory) instead.
> >
> > I really don't want some kind of top-level CI for the base kernel project.
> >
> > We already have the situation that the drm people have their own ci
> > model. II'm ok with that, partly because then at least the maintainers
> > of that subsystem can agree on the rules for that one subsystem.
> >
> > I'm not at all interested in having something that people will then
> > either fight about, or - more likely - ignore, at the top level
> > because there isn't some global agreement about what the rules are.
> >
> > For example, even just running checkpatch is often a stylistic thing,
> > and not everybody agrees about all the checkpatch warnings.
> >
> 
> While checkpatch is indeed of arguable value, I think it would help a
> lot not having to bother about the persistent _build_ failures on
> 32-bit systems. You mentioned the fancy drm CI system above, but they
> don't run tests and not even test builds on 32-bit targets, which has
> repeatedly caused (and currently does cause) build failures in drm
> code when trying to build, say, arm:allmodconfig in linux-next. Most
> trivial build failures in linux-next (and, yes, sometimes mainline)
> could be prevented with a simple generic CI.

Ultimately, the question here is about funding. Can we expect DRM CI to
pay for builders out of the X.org foundation pocket to build kernel
configurations that are seeing close to no development (arm), or not
having any driver for (xtensa, m68k)?

And if we would turn the argument around, I don't really expect, say,
the clock framework, to validate that all DRM kunit tests pass for each
commit they merge, even though one of them could totally break some of
the DRM tests.

If anything, it's more of a side-effect to the push for COMPILE_TEST
than anything.

Maxime

Attachment: signature.asc
Description: PGP signature