> -----Original Message----- > From: Helen Mae Koike Fornazier <helen.koike@xxxxxxxxxxxxx> > Hi Mauro, > > ---- On Fri, 24 Jan 2025 12:29:16 -0300 Mauro Carvalho Chehab wrote --- > > > Em Fri, 24 Jan 2025 09:26:33 -0500 > > Nicolas Dufresne nicolas.dufresne@xxxxxxxxxxxxx> escreveu: > > > > > Hi, > > > > > > Le vendredi 24 janvier 2025 à 15:00 +0200, Nikolai Kondrashov a écrit : > > > > On 1/24/25 2:16 PM, Jarkko Sakkinen wrote: > > > > > On Fri Jan 24, 2025 at 10:12 AM EET, Laurent Pinchart wrote: > > > > > > Gitlab as an open-source software project (the community edition) is one > > > > > > thing, but can we please avoid advertising specific proprietary services > > > > > > in the kernel documentation ? > > > > > > > > > > I don't think we should have any of this in the mainline kernel. > > > > > > > > > > One angle is that "no regressions rule" applies also to the shenanigans. > > > > > > > > > > Do we really spend energy on this proprietary crap to the eternity? > > > > > > > > This is not getting included into the kernel itself, the contributed code is, > > > > of course, open-source. And yes it would execute just fine on the fully > > > > open-source community-edition GitLab. > > > > > > I don't think "no regressions rule" should apply here. > > > > It doesn't, as this is not a Kernel userspace API. It is just some > > facility to integrate Kernel builds using a CI infrastructure. This can > > change with time as needed. > > > > Still, once people start using it, developers need to take some care to > > avoid regressions that would cause CI builds to fail for the ones using > > such facilities. > > > > Also, ideally, this should be completely independent of the Kernel version, > > e.g. if one sets up an infra using the version that was there when, let's > > say, Kernel 6.14 is released, the same CI scripts should work just fine > > with stable Kernels and even future Kernels. > > Or you can just configure your GitLab CI to work and an older version of > the script by just pointing the right yaml URL at that versions in the configs, > or am I missing something? > > > > > Due to that, I'm not convinced that such kernel CI files should be > > hosted at the Kernel tree. > > > > IMO, this should be stored on a separate repository hosted at > > kernel.org, using Semantic Versoning (https://semver.org/) - e. g. > > when there are incompatible changes, major version number will be > > increased. > > A key benefit of having it in-tree is the test expectation list, as seen with > DRM-CI. This allows developers to track the state of drivers and progress over > time by showing which tests are expected to pass or fail at a given point in > history. (From what I see in DRM-CI, this adds a considerable amount of value.) > Please check the VKMS patch in this patchset. > > Also, if we keep this tool out of tree, I’m concerned that subsystems like DRM > and Media will continue not collaborating—each currently has its own solution > when the base could be shared and reused. All static checks, build processes, > and boot mechanisms are fundamentally the same, with only minor differences > that are customizable. Other subsystems could use just the base or build their > specific configurations/tests on top of it. > Having it in-tree sends a message: "You can create your own GitLab CI pipeline, > but why not use this existing one, contribute to it, and collaborate for > everyone's benefit?". > Since it's under the tools/ folder, it’s a helper tool. Although I don't use gitlab CI for my kernel testing (I use Fuego), I've been waiting for this so that I can see if it's possible to leverage the information contained in it for my own CI system. I may not end up using the info myself, but at a minimum it will show me the info needed by another CI system. Having this upstream is useful, IMHO, even if it just reflects a single CI system currently being used. -- Tim > > > > This is for developers only, and is a template for making > > > > your own pipeline mostly, with pieces which can be reused. > > > > > > Perhpas worth clarifying that Media and DRM subsystem have opted for the > > > Freedesktop instance. This instance is running the Open Source version of > > > Gitlab, with hundreds of CI runners contributed and shared among many projects > > > (which includes Mesa, GStreamer, Wayland, Pipewire, libcamera, just to name > > > few). > > > > It doesn't matter much what git forge some projects are currently using, as > > things like that could change with time. > > > > Starting with supporting just one type of git forge sounds OK to me, > > but long term goal should be to make it generic enough to be used with as > > much CI engines as possible - not only forges developed by companies that > > provide paid services like Gitlab/Github, but also completely open > > source forges and even Jenkins. > > > > Thanks, > > Mauro > > >
