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.
Attachment:
signature.asc
Description: PGP signature
