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
--
An old man doll... just what I always wanted! - Clara
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.
Thanks
Helen
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
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
>