linux-kernel - Re: Automatically update drm CI dependencies?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 8 Jan 2024 11:53:24 -0300
From: Helen Koike <helen.koike@...labora.com>
To: Bagas Sanjaya <bagasdotme@...il.com>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Linux DRI Development <dri-devel@...ts.freedesktop.org>
Cc: David Heidelberg <david.heidelberg@...labora.com>,
 Dorine Tipo <dorine.a.tipo@...il.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: Automatically update drm CI dependencies?

On 20/12/2023 08:11, Bagas Sanjaya wrote:
> On 12/19/23 23:43, Helen Koike wrote:
>> Hi,
>>
>> On 14/12/2023 06:38, Bagas Sanjaya wrote:
>>> Hi all,
>>>
>>> I'm referring to dependabot PR on torvalds.git GitHub mirror [1]. I know
>>> that PRs submitted there are not accepted (the repo is essentially read-only
>>> mirror), hence this mail question.
>>>
>>> In summary, dependabot submitted automated PR that bumps package versions
>>> in `drivers/gpu/drm/ci/xfails/requirements.txt`. In this case, pip was
>>> upgraded to 23.3.
>>>
>>>   From my experience, such automated PRs can pollute commit history (in
>>> some GitHub projects these PR kind can contribute up to half of total
>>> commits since the beginning of project). And in some projects, dependabot
>>> PRs are automatically merged without any maintainer intervention.
>>>
>>> Does such PRs (when submitted to LKML these will be patches) make sense
>>> for DRM subsystem?
>>>
>>> Thanks.
>>>
>>> [1]: https://github.com/torvalds/linux/pull/807
>>>
>>
>> imho I rather not having this automated patches, but I would like to hear the opinions from others.
>>
> 
> But why? Did you mean that making the CI always depends on latest version
> of dependencies create another maintenance variable (and may constantly
> broke CI)?
> 
> Confused...

Sorry I didn't reply earlier.

I'm ok with that if it doesn't produce much noise, I also think that we 
need an automated test to see if the tool is still working as expected 
before merging the patch.
The pip there is just used for a helper tool, it is nothing critical.

Regards,
Helen

>