On 2024-02-29 21:21, Linus Torvalds wrote:
On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov spbnick@gmail.com 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.
I would suggest the CI project be separate from the kernel.
That would be missing a lot of the point / benefit of CI.
A CI system which is separate from the kernel will tend to be out of sync, so it can't gate the merging of changes and thus can't prevent regressions from propagating.