Re: [PATCH 1/5] dt-bindings: media: i2c: Add bindings for OX05B1S sensor driver

Re: [PATCH 1/5] dt-bindings: media: i2c: Add bindings for OX05B1S sensor driver

[Laurent Pinchart]

(CC'ing the devicetree mailing list)

On Tue, Oct 29, 2024 at 01:28:51PM +0100, Krzysztof Kozlowski wrote:
> On 29/10/2024 13:21, Laurent Pinchart wrote:
> > On Tue, Oct 29, 2024 at 01:15:46PM +0100, Krzysztof Kozlowski wrote:
> >> On 29/10/2024 13:10, Laurent Pinchart wrote:
> >>> On Tue, Oct 29, 2024 at 07:14:28AM +0100, Krzysztof Kozlowski wrote:
> >>>> On 28/10/2024 20:06, Mirela Rabulea wrote:
> >>>>> Add bindings for OX05B1S sensor driver
> >>>>>
> >>>>> Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
> >>>>
> >>>> <form letter>
> >>>> Please use scripts/get_maintainers.pl to get a list of necessary people
> >>>> and lists to CC. It might happen, that command when run on an older
> >>>> kernel, gives you outdated entries. Therefore please be sure you base
> >>>> your patches on recent Linux kernel.
> >>>>
> >>>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> >>>> people, so fix your workflow. Tools might also fail if you work on some
> >>>> ancient tree (don't, instead use mainline) or work on fork of kernel
> >>>> (don't, instead use mainline). Just use b4 and everything should be
> >>>> fine, although remember about `b4 prep --auto-to-cc` if you added new
> >>>> patches to the patchset.
> >>>>
> >>>> You missed at least devicetree list (maybe more), so this won't be
> >>>> tested by automated tooling. Performing review on untested code might be
> >>>> a waste of time.
> >>>>
> >>>> Please kindly resend and include all necessary To/Cc entries.
> >>>> </form letter>
> >>>>
> >>>> Binding also looks very different than all other devices, so re-write it
> >>>> starting from EXISTING GOOD bindings. Not some downstream stuff.
> >>>
> >>> Krzysztof, please point to a good example when making this kind of
> >>> comment.
> >>
> >> Anything recently added. Git log tells which files were recently added.
> > 
> > If the review comment is a copy&paste (given that you review lots of
> > bindings and constantly have to repeat the same things, that would make
> > sense), expanding it with that information for future reviews could help
> > patch authors. Thanks for considering it, it would be much appreciated.
> 
> Sorry, but that's not the point. You do not take 10 yo, unmaintained
> driver and use it as template for your new one. Instead you rather take
> something recent or something which you know is correct. Same with bindings.

I wouldn't know for sure which driver or binding was used as a starting
point. My point was unrelated to this particular patch series. I think
that including clear information in ready-made answers will help
everybody. It will tell the submitters what they need to know, it will
avoid this kind of conversation being repeated, and it could even in the
end increase the quality of submissions. Even better, it won't cost
anything to add it to answer templates.

> NXP is not a small company which does not know how to use Linux or how
> to upstream stuff. This is not individual's contribution, where one does
> not have colleagues or 3 billions USD of revenue behind, to be able to
> get some internal help prior sending something downstream.
> 
> They can spend something out of these 3 billions of revenue or 700
> millions of net income to hire you guys or any other open-source
> company, if basics of upstreaming are unknown.
>
> That's the comment I was giving about NXP since a year. Some things
> around SoC improved, some things from this unit of NXP here did not
> change at all.

If I were on the receiving end of this, as an individual developer, I
would consider it very patronizing and insulting. Treating the authors
of contributions you don't consider as good enough in such a harsh way
will not improve the situation, and will drive people away. You may be
frustrated by some companies, but this kind of comment will not help.
Please soften your tone towards individual developers, they're not
punching balls on which to dump frustration and anger. Firm and polite
will work better than lashing out.

> So again, it's not about me giving them more things. They will keep
> ignoring it over and over, because that's how big companies sometimes
> behave. You know, community people work for free, right?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/5] dt-bindings: media: i2c: Add bindings for OX05B1S sensor driver

[Krzysztof Kozlowski]

On 29/10/2024 13:46, Laurent Pinchart wrote:
> (CC'ing the devicetree mailing list)
> 
> On Tue, Oct 29, 2024 at 01:28:51PM +0100, Krzysztof Kozlowski wrote:
>> On 29/10/2024 13:21, Laurent Pinchart wrote:
>>> On Tue, Oct 29, 2024 at 01:15:46PM +0100, Krzysztof Kozlowski wrote:
>>>> On 29/10/2024 13:10, Laurent Pinchart wrote:
>>>>> On Tue, Oct 29, 2024 at 07:14:28AM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 28/10/2024 20:06, Mirela Rabulea wrote:
>>>>>>> Add bindings for OX05B1S sensor driver
>>>>>>>
>>>>>>> Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
>>>>>>
>>>>>> <form letter>
>>>>>> Please use scripts/get_maintainers.pl to get a list of necessary people
>>>>>> and lists to CC. It might happen, that command when run on an older
>>>>>> kernel, gives you outdated entries. Therefore please be sure you base
>>>>>> your patches on recent Linux kernel.
>>>>>>
>>>>>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
>>>>>> people, so fix your workflow. Tools might also fail if you work on some
>>>>>> ancient tree (don't, instead use mainline) or work on fork of kernel
>>>>>> (don't, instead use mainline). Just use b4 and everything should be
>>>>>> fine, although remember about `b4 prep --auto-to-cc` if you added new
>>>>>> patches to the patchset.
>>>>>>
>>>>>> You missed at least devicetree list (maybe more), so this won't be
>>>>>> tested by automated tooling. Performing review on untested code might be
>>>>>> a waste of time.
>>>>>>
>>>>>> Please kindly resend and include all necessary To/Cc entries.
>>>>>> </form letter>
>>>>>>
>>>>>> Binding also looks very different than all other devices, so re-write it
>>>>>> starting from EXISTING GOOD bindings. Not some downstream stuff.
>>>>>
>>>>> Krzysztof, please point to a good example when making this kind of
>>>>> comment.
>>>>
>>>> Anything recently added. Git log tells which files were recently added.
>>>
>>> If the review comment is a copy&paste (given that you review lots of
>>> bindings and constantly have to repeat the same things, that would make
>>> sense), expanding it with that information for future reviews could help
>>> patch authors. Thanks for considering it, it would be much appreciated.
>>
>> Sorry, but that's not the point. You do not take 10 yo, unmaintained
>> driver and use it as template for your new one. Instead you rather take
>> something recent or something which you know is correct. Same with bindings.
> 
> I wouldn't know for sure which driver or binding was used as a starting
> point. My point was unrelated to this particular patch series. I think
> that including clear information in ready-made answers will help
> everybody. It will tell the submitters what they need to know, it will
> avoid this kind of conversation being repeated, and it could even in the
> end increase the quality of submissions. Even better, it won't cost
> anything to add it to answer templates.
> 
>> NXP is not a small company which does not know how to use Linux or how
>> to upstream stuff. This is not individual's contribution, where one does
>> not have colleagues or 3 billions USD of revenue behind, to be able to
>> get some internal help prior sending something downstream.
>>
>> They can spend something out of these 3 billions of revenue or 700
>> millions of net income to hire you guys or any other open-source
>> company, if basics of upstreaming are unknown.
>>
>> That's the comment I was giving about NXP since a year. Some things
>> around SoC improved, some things from this unit of NXP here did not
>> change at all.
> 
> If I were on the receiving end of this, as an individual developer, I
> would consider it very patronizing and insulting. Treating the authors
> of contributions you don't consider as good enough in such a harsh way
> will not improve the situation, and will drive people away. You may be
> frustrated by some companies, but this kind of comment will not help.
> Please soften your tone towards individual developers, they're not
> punching balls on which to dump frustration and anger. Firm and polite
> will work better than lashing out.

I would be very happy to tell it to the managers, decision makers and
CEOs, but they avoid me. :/

Best regards,
Krzysztof