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] [thread-next>] [day] [month] [year] [list]
Message-ID: <846e883c-e3ae-426f-83e3-38e357e53ef3@gmail.com>
Date: Wed, 20 Dec 2023 18:11:25 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Helen Koike <helen.koike@...labora.com>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Linux DRI Development <dri-devel@...ts.freedesktop.org>
Cc: Thomas Zimmermann <tzimmermann@...e.de>,
 Maxime Ripard <mripard@...nel.org>,
 David Heidelberg <david.heidelberg@...labora.com>,
 Dorine Tipo <dorine.a.tipo@...il.com>
Subject: Re: Automatically update drm CI dependencies?

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...

-- 
An old man doll... just what I always wanted! - Clara


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ