On Mon, Mar 04, 2024 at 06:45:33PM -0300, Helen Koike wrote:
> Hi Linus,
>
> Thank you for your reply and valuable inputs.
>
> On 01/03/2024 17:10, Linus Torvalds wrote:
> > On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
> > >
> > > I agree, it's hard to imagine even a simple majority a
Hi Nicolas,
On Thu, Mar 07, 2024 at 01:05:12PM -0500, Nicolas Dufresne wrote:
> Le jeudi 29 février 2024 à 10:02 +0100, Maxime Ripard a écrit :
> > On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
> > > This patch introduces a `.gitlab-ci` file along with a `ci/` folder,
> > > defining
On Mon, 2024-03-04 at 18:45 -0300, Helen Koike wrote:
> Hi Linus,
>
> Thank you for your reply and valuable inputs.
>
> On 01/03/2024 17:10, Linus Torvalds wrote:
> > On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
> > >
> > > I agree, it's hard to imagine even a simple majority agreeing
Le jeudi 29 février 2024 à 10:02 +0100, Maxime Ripard a écrit :
> Hi Helen,
>
> Thanks for working on this
>
> On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
> > This patch introduces a `.gitlab-ci` file along with a `ci/` folder,
> > defininga basic test pipeline triggered by code
On 2024-02-29 21:21, Linus Torvalds wrote:
> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov 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
Hi Linus,
Thank you for your reply and valuable inputs.
On 01/03/2024 17:10, Linus Torvalds wrote:
On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
should be done. Still, we would like to help people, who ar
On Mon, Mar 4, 2024 at 9:09 AM Maxime Ripard wrote:
[ ...]
>
> 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
On Mon, Mar 4, 2024 at 9:09 AM Maxime Ripard wrote:
> 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
On Mon, Mar 04, 2024 at 08:17:22AM -0800, Guenter Roeck wrote:
> On Mon, Mar 4, 2024 at 8:05 AM Maxime Ripard 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 wrote:
> > > [ ... ]
> > > >
> > > > If anything, it's mor
On Mon, Mar 4, 2024 at 8:05 AM Maxime Ripard 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 wrote:
> > [ ... ]
> > >
> > > If anything, it's more of a side-effect to the push for COMPILE_TEST
> > > than anything.
> > >
>
On Mon, Mar 04, 2024 at 07:46:34AM -0800, Guenter Roeck wrote:
> On Mon, Mar 4, 2024 at 1:24 AM Maxime Ripard 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 wit
On Mon, Mar 4, 2024 at 1:24 AM Maxime Ripard 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 doe
On Mon, Mar 04, 2024 at 12:12:47PM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Mon, Mar 4, 2024 at 11:20 AM Maxime Ripard wrote:
> > On Mon, Mar 04, 2024 at 11:07:22AM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard wrote:
> > > > On Mon, Mar 04, 202
Hi Maxime,
On Mon, Mar 4, 2024 at 11:20 AM Maxime Ripard wrote:
> On Mon, Mar 04, 2024 at 11:07:22AM +0100, Geert Uytterhoeven wrote:
> > On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard wrote:
> > > On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote:
> > > > On Sun, Mar 3, 2024 at
On Mon, Mar 04, 2024 at 11:07:22AM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard wrote:
> > On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote:
> > > On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven
> > > wrote:
> > > > On Sun,
Hi Maxime,
On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard wrote:
> On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote:
> > On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven
> > wrote:
> > > On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> > > > On 3/2/24 14:10, Guenter Roec
On Sat, Mar 02, 2024 at 02:10:51PM -0800, Guenter Roeck wrote:
> On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> wrote:
> >
> > On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
> > >
> > > However, I think a better approach would be *not* to add the
> > > .gitlab-ci.yaml
> > > file in t
On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote:
> On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven
> wrote:
> > On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> > > On 3/2/24 14:10, Guenter Roeck wrote:
> > > > While checkpatch is indeed of arguable value, I think it wo
On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven wrote:
> On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> > On 3/2/24 14:10, Guenter Roeck wrote:
> > > While checkpatch is indeed of arguable value, I think it would help a
> > > lot not having to bother about the persistent _build_ failures
On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> On 3/2/24 14:10, Guenter Roeck wrote:
> > On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> > wrote:
> >> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
> >>>
> >>> However, I think a better approach would be *not* to add the
> >>> .
On 3/2/24 14:10, Guenter Roeck wrote:
> On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> wrote:
>>
>> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov 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 inste
On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
wrote:
>
> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov 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 poi
On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
>
> I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
> should be done. Still, we would like to help people, who are interested in
> this kind of thing, to set it up. How about we reframe this contribution as a
> s
On 3/1/24 4:07 PM, Mark Brown wrote:
On Fri, Mar 01, 2024 at 12:27:13PM +0200, Nikolai Kondrashov wrote:
On 2/29/24 10:21 PM, Linus Torvalds wrote:
I would suggest the CI project be separate from the kernel.
It is possible to have a GitLab CI setup with the YAML files in a separate
repositor
On Fri, Mar 01, 2024 at 12:27:13PM +0200, Nikolai Kondrashov wrote:
> On 2/29/24 10:21 PM, Linus Torvalds wrote:
> > 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
Thanks for stopping by, Linus!
On 2/29/24 10:21 PM, Linus Torvalds wrote:
> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov 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
>>
On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov 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
Hi Tim,
just replying below to one of your comment which I happen to be involved in, but
I'll let others reply for the more specific comments.
Le jeudi 29 février 2024 à 02:44 +, Bird, Tim a écrit :
> > -Original Message-
> > From: Helen Koike
> >
>
>
> > Hey all,
> >
> > You
On Thu, Feb 29, 2024 at 10:56:58AM +0100, Maxime Ripard wrote:
> Hi!
>
> On Thu, Feb 29, 2024 at 11:23:22AM +0200, Nikolai Kondrashov wrote:
> > Hi everyone,
> >
> > On 2/29/24 11:02, Maxime Ripard wrote:
> > > On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
> > > > Which rating woul
Hi!
On Thu, Feb 29, 2024 at 11:23:22AM +0200, Nikolai Kondrashov wrote:
> Hi everyone,
>
> On 2/29/24 11:02, Maxime Ripard wrote:
> > On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
> > > Which rating would you select?
> >
> > 4.5 :)
> >
> > One thing I'm wondering here is how we'r
Hi everyone,
On 2/29/24 11:02, Maxime Ripard wrote:
On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
Which rating would you select?
4.5 :)
One thing I'm wondering here is how we're going to cope with the
different requirements each user / framework has.
Like, Linus probably want
Hi Helen,
Thanks for working on this
On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
> This patch introduces a `.gitlab-ci` file along with a `ci/` folder,
> defininga basic test pipeline triggered by code pushes to a GitLab-CI
> instance. This initial version includes static checks
> -Original Message-
> From: Helen Koike
>
> Hey all,
>
> You can check the validation of this patchset on:
> https://gitlab.collabora.com/koike/linux/-/pipelines/87035
>
> I would appreciate your feedback on this work, what do you think?
>
> If you would rate from 0 to 5
This patch introduces a `.gitlab-ci` file along with a `ci/` folder,
defininga basic test pipeline triggered by code pushes to a GitLab-CI
instance. This initial version includes static checks (checkpatch and
smatch for now) and build tests across various architectures and
configurations. It levera
34 matches
Mail list logo
