From: Maxime Ripard <mripard@kernel.org>
To: Guenter Roeck <groeck@google.com>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>,
Nikolai Kondrashov <spbnick@gmail.com>,
Helen Koike <helen.koike@collabora.com>,
linuxtv-ci@linuxtv.org, dave.pigott@collabora.com,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kselftest@vger.kernel.org, gustavo.padovan@collabora.com,
pawiecz@collabora.com, tales.aparecida@gmail.com,
workflows@vger.kernel.org, kernelci@lists.linux.dev,
skhan@linuxfoundation.org, kunit-dev@googlegroups.com,
nfraprado@collabora.com, davidgow@google.com, cocci@inria.fr,
Julia.Lawall@inria.fr, laura.nao@collabora.com,
ricardo.canuelo@collabora.com, kernel@collabora.com,
gregkh@linuxfoundation.org
Subject: Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Date: Mon, 4 Mar 2024 18:09:31 +0100 [thread overview]
Message-ID: <20240304-benevolent-brawny-urchin-0af0ad@houat> (raw)
In-Reply-To: <CABXOdTeDydWO9mf2yxWjjebHZ1bE=R2HPs1P4XYwNhzznNKxmw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]
On Mon, Mar 04, 2024 at 08:17:22AM -0800, Guenter Roeck wrote:
> On Mon, Mar 4, 2024 at 8:05 AM Maxime Ripard <mripard@kernel.org> wrote:
> >
> > On Mon, Mar 04, 2024 at 07:46:34AM -0800, Guenter Roeck wrote:
> > > On Mon, Mar 4, 2024 at 1:24 AM Maxime Ripard <mripard@kernel.org> wrote:
> > > [ ... ]
> > > >
> > > > If anything, it's more of a side-effect to the push for COMPILE_TEST
> > > > than anything.
> > > >
> > >
> > > If the drm subsystem maintainers don't want people to build it with
> > > COMPILE_TEST while at the same time not limiting it to platforms where
> > > it doesn't even build, I'd suggest making it dependent on
> > > !COMPILE_TEST.
> >
> > I don't think we want anything. My point was that you can't have an
> > option that is meant to explore for bad practices and expose drivers
> > that don't go through the proper abstraction, and at the same time
> > complain that things gets broken. It's the whole point of it.
> >
> Can we get back to the original problem, please ?
Sure.
> Build errors such as failed 32-bit builds are a nuisance for those
> running build tests. It seems to me that an automated infrastructure
> to prevent such build errors from making it into the kernel should be
> desirable. You seem to disagree, and at least it looked like you
> complained about the existence of COMPILE_TEST, or that people are
> doing COMPILE_TEST builds. What is your suggested alternative ?
> Disabling build tests on drm doesn't seem to be it, and it seems you
> don't like the idea of a basic generic CI either, but what is it ?
You don't have to be aggressive about it though. Anyway. The original
problem I pointed out was funding. You can't expect everyone to pay for
builders running things they fundamentally don't care about.
That's it.
I'm all for CI, I'm all for automated tests and builds, I don't think
COMPILE_TEST is a bad idea, I also think doing those kind of builds is
worth it and useful.
But the point of those exploratory kind of builds is precisely to look
for breakages, so is something we should expect, not complain about.
There's nothing to fix, or nothing to improve to me, except the general
discourse.
And singling out DRM because it regularly allegedly breaks things on
xtensa or m68k and claiming we're not taking CI seriously because of it
is completely ridiculous. If the all the subsystems were taking CI as
seriously as DRM, we would be in a much better place.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-03-04 17:09 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 22:55 [PATCH 0/3] " Helen Koike
2024-02-28 22:55 ` [PATCH 1/3] " Helen Koike
2024-02-29 2:44 ` Bird, Tim
2024-02-29 16:15 ` Nicolas Dufresne
2024-02-29 9:02 ` Maxime Ripard
2024-02-29 9:23 ` Nikolai Kondrashov
2024-02-29 9:56 ` Maxime Ripard
2024-02-29 10:05 ` Laurent Pinchart
2024-02-29 20:21 ` Linus Torvalds
2024-03-01 10:27 ` Nikolai Kondrashov
2024-03-01 14:07 ` Mark Brown
2024-03-01 14:21 ` Nikolai Kondrashov
2024-03-01 20:10 ` Linus Torvalds
2024-03-04 21:45 ` Helen Koike
2024-03-07 22:43 ` Leonardo Brás
2024-05-23 13:21 ` Daniel Vetter
2024-03-02 22:10 ` Guenter Roeck
2024-03-03 0:01 ` Randy Dunlap
2024-03-03 9:30 ` Geert Uytterhoeven
2024-03-04 8:12 ` Geert Uytterhoeven
2024-03-04 9:15 ` Maxime Ripard
2024-03-04 10:07 ` Geert Uytterhoeven
2024-03-04 10:19 ` Maxime Ripard
2024-03-04 11:12 ` Geert Uytterhoeven
2024-03-04 11:28 ` Maxime Ripard
2024-03-04 9:24 ` Maxime Ripard
2024-03-04 15:46 ` Guenter Roeck
2024-03-04 16:05 ` Maxime Ripard
2024-03-04 16:17 ` Guenter Roeck
2024-03-04 17:09 ` Maxime Ripard [this message]
2024-03-04 17:22 ` Guenter Roeck
2024-03-04 19:44 ` Guenter Roeck
2024-03-05 11:54 ` Michel Dänzer
2024-03-07 18:05 ` Nicolas Dufresne
2024-03-11 8:40 ` Maxime Ripard
2024-02-28 22:55 ` [PATCH 2/3] kci-gitlab: Add documentation Helen Koike
2024-02-28 22:55 ` [PATCH 3/3] kci-gitlab: docs: Add images Helen Koike
2024-02-28 23:07 ` [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing Laurent Pinchart
2024-02-29 8:43 ` Maxime Ripard
2024-02-29 9:26 ` Nikolai Kondrashov
2024-02-29 9:34 ` Laurent Pinchart
2024-02-29 11:10 ` Nikolai Kondrashov
2024-02-29 11:19 ` Laurent Pinchart
2024-02-29 11:22 ` Nikolai Kondrashov
2024-02-29 11:41 ` Mark Brown
2024-02-29 11:53 ` Guillaume Tucker
2024-02-29 12:20 ` Laurent Pinchart
2024-02-29 12:25 ` Laurent Pinchart
2024-02-29 14:12 ` Nikolai Kondrashov
2024-02-29 9:39 ` Sakari Ailus
2024-02-29 11:09 ` Mark Brown
2024-02-29 12:20 ` Guillaume Tucker
2024-02-29 14:16 ` Nikolai Kondrashov
2024-02-29 16:28 ` Nicolas Dufresne
2024-03-01 21:56 ` Guillaume Tucker
2024-03-02 21:48 ` Gustavo Padovan
2024-03-04 8:33 ` Guillaume Tucker
2024-05-21 9:28 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240304-benevolent-brawny-urchin-0af0ad@houat \
--to=mripard@kernel.org \
--cc=Julia.Lawall@inria.fr \
--cc=cocci@inria.fr \
--cc=dave.pigott@collabora.com \
--cc=davidgow@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@google.com \
--cc=gustavo.padovan@collabora.com \
--cc=helen.koike@collabora.com \
--cc=kernel@collabora.com \
--cc=kernelci@lists.linux.dev \
--cc=kunit-dev@googlegroups.com \
--cc=laura.nao@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linuxtv-ci@linuxtv.org \
--cc=nfraprado@collabora.com \
--cc=pawiecz@collabora.com \
--cc=ricardo.canuelo@collabora.com \
--cc=skhan@linuxfoundation.org \
--cc=spbnick@gmail.com \
--cc=tales.aparecida@gmail.com \
--cc=torvalds@linuxfoundation.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox