Message-ID:
 <MW5PR13MB5632647364D67725756B77FBFDE32@MW5PR13MB5632.namprd13.prod.outlook.com>
Date: Fri, 24 Jan 2025 19:59:05 +0000
From: "Bird, Tim" <Tim.Bird@...y.com>
To: Helen Mae Koike Fornazier <helen.koike@...labora.com>,
        Mauro Carvalho
 Chehab <mchehab+huawei@...nel.org>
CC: Nicolas Dufresne <nicolas.dufresne@...labora.com>,
        Nikolai Kondrashov
	<Nikolai.Kondrashov@...hat.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Laurent
 Pinchart <laurent.pinchart@...asonboard.com>,
        "Leonardo Brás" <leobras.c@...il.com>,
        Vignesh Raman
	<vignesh.raman@...labora.com>,
        kernelci <kernelci@...ts.linux.dev>,
        linuxtv-ci <linuxtv-ci@...uxtv.org>,
        dave.pigott <dave.pigott@...labora.com>, mripard <mripard@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-kselftest
	<linux-kselftest@...r.kernel.org>,
        gustavo.padovan
	<gustavo.padovan@...labora.com>,
        pawiecz <pawiecz@...labora.com>, spbnick
	<spbnick@...il.com>,
        tales.aparecida <tales.aparecida@...il.com>,
        workflows
	<workflows@...r.kernel.org>,
        skhan <skhan@...uxfoundation.org>,
        kunit-dev
	<kunit-dev@...glegroups.com>,
        nfraprado <nfraprado@...labora.com>, davidgow
	<davidgow@...gle.com>,
        cocci <cocci@...ia.fr>, Julia.Lawall
	<Julia.Lawall@...ia.fr>,
        laura.nao <laura.nao@...labora.com>, kernel
	<kernel@...labora.com>,
        torvalds <torvalds@...uxfoundation.org>,
        gregkh
	<gregkh@...uxfoundation.org>, daniels <daniels@...labora.com>,
        shreeya.patel
	<shreeya.patel@...labora.com>,
        denys.f <denys.f@...labora.com>,
        louis.chauvet
	<louis.chauvet@...tlin.com>,
        hamohammed.sa <hamohammed.sa@...il.com>,
        melissa.srw <melissa.srw@...il.com>, simona <simona@...ll.ch>,
        airlied
	<airlied@...il.com>, broonie <broonie@...nel.org>,
        groeck
	<groeck@...gle.com>, rdunlap <rdunlap@...radead.org>,
        geert
	<geert@...ux-m68k.org>,
        michel.daenzer <michel.daenzer@...lbox.org>,
        sakari.ailus <sakari.ailus@....fi>
Subject: RE: [PATCH v2 0/5] kci-gitlab: Introducing GitLab-CI Pipeline for
 Kernel Testing



> -----Original Message-----
> From: Helen Mae Koike Fornazier <helen.koike@...labora.com>
> 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@...labora.com> 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
>  >
> 

Powered by blists - more mailing lists