U-Boot patch submit standard and requirement

[Neil Armstrong]

On 5/19/26 00:05, Sune Brian wrote:
> On Tue, May 19, 2026 at 3:17 AM Neil Armstrong
> <neil.armstrong at linaro.org> wrote:
>>
>> On 5/16/26 01:11, Sune Brian wrote:
>>> On Fri, May 15, 2026 at 11:02 PM Tom Rini <trini at konsulko.com> wrote:
>>>>
>>>> On Fri, May 15, 2026 at 04:23:49PM +0800, Sune Brian wrote:
>>>>> On Fri, May 15, 2026 at 3:46 PM Conor Dooley <conor.dooley at microchip.com> wrote:
>>>>>>
>>>>>> On Fri, May 15, 2026 at 08:46:25AM +0800, Sune Brian wrote:
>>>>>>> On Fri, May 15, 2026 at 12:14 AM Conor Dooley <conor at kernel.org> wrote:
>>>>>>>>
>>>>>>>> On Thu, May 14, 2026 at 07:46:46PM +0800, Sune Brian wrote:
>>>>>>>>> On Thu, May 14, 2026 at 6:37 PM Peter Robinson <pbrobinson at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Brian,
>>>>>>>>>>
>>>>>>>>>> You have made a very generic statement about levels of accountability
>>>>>>>>>> on patch sets and consistency in reviews.
>>>>>>>>>>
>>>>>>>>>> Can you be more specific?
>>>>>>>>>>
>>>>>>>>>> Ultimately there are subsystem maintainers and each maintainer has
>>>>>>>>>> variation on how they deal with their subsystem. You reference one doc
>>>>>>>>>> three times in your statement.
>>>>>>>>>
>>>>>>>>> Hi Peter,
>>>>>>>>>
>>>>>>>>> Now I understand what you mean.
>>>>>>>>> Simply one sentence is a bit hard to read what your thoughts are.
>>>>>>>>>
>>>>>>>>> That document I am quoting does not refer to the entire docs but only one
>>>>>>>>> section of the docs with that link.
>>>>>>>>>
>>>>>>>>> Before quoting, my declarations as follows:
>>>>>>>>> 1) I am not referring to specific people or party
>>>>>>>>> 2) I experienced reviewer which again not being specific to one that
>>>>>>>>> mentioned this docs is a supreme rules to follow otherwise patch
>>>>>>>>> that is committed is not able to push to mainstream
>>>>>>>>> 3) I simply do a quick check on u-boot mailing pool and do see a lot
>>>>>>>>> of uncompiled reviewed patches that are not following that supreme
>>>>>>>>> docs.
>>>>>>>>>
>>>>>>>>> As such I will being to quote:
>>>>>>>>>
>>>>>>>>> The mailing that are reported as not passing the standard of [1]
>>>>>>>>> Full mailing:
>>>>>>>>> https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3684415
>>>>>>>>
>>>>>>>> patchwork isn't loading for me, but it's on lore here:
>>>>>>>> https://lore.kernel.org/all/20260423042824.3480-1-briansune@gmail.com/
>>>>>>>>
>>>>>>>
>>>>>>> Hi Dooley,
>>>>>>>
>>>>>>> Well I am sure you did not have the full picture.
>>>>>>>
>>>>>>> The request had nothing to do with under the --- line if this is
>>>>>>> really the case:
>>>>>>
>>>>>>> Let me bring you back to the history of wonders:
>>>>>>>
>>>>>>> https://patchwork.ozlabs.org/project/uboot/patch/20260421004719.73491-1-briansune@gmail.com/#3680232
>>>>>>>
>>>>>>> https://patchwork.ozlabs.org/project/uboot/patch/20260422065910.5398-1-briansune@gmail.com/
>>>>>>>
>>>>>>> None of those reviewers had mentioned this issue once "---" rather they all
>>>>>>> just alarmingly repeated the wordings.
>>>>>>
>>>>>> The first mail in the thread mentions it:
>>>>>> https://lore.kernel.org/all/CAFLszThg=EamyRohxNA7V+nk+OMVK356nUjAVSbu4+kokOJpdA@mail.gmail.com/
>>>>>>
>>>>>>>
>>>>>>>> The comment about the changelog format seems to be very harsh, I doubt
>>>>>>>> it really makes any difference. What you did and what the maintainer
>>>>>>>> requested are effectively the same thing at the end of the day.
>>>>>>>>
>>>>>>>
>>>>>>> Of course after reading the docs I got it immediately.
>>>>>>> However did those who request contributors quote this from first place?
>>>>>>>
>>>>>>>> The real problem with your patch is that you put the changelog into the
>>>>>>>> commit message itself, rather than under the --- line.
>>>>>>>> None of the examples you quote below do that.
>>>>>>>>
>>>>>>>
>>>>>>> Well after 4 patches of ridiculous request and logic change.
>>>>>>> I guess you will do the same. At least I am not doing it at the
>>>>>>> first moment on replying to the mails who or whom you had mentioned.
>>>>>>
>>>>>> I think this is a reply to the comment below?
>>>>>> The aggressive/antagonistic responses begin in your first reply to
>>>>>> Simon:
>>>>>> https://lore.kernel.org/all/CAN7C2SAdg1MX3ZfEt5-68iiw3pdjyqva48F_uJjNwsHAhdmY3Q@mail.gmail.com/
>>>>>> "So forgive me I really don't give a damn on whatever the header
>>>>>> requirements." "There are many better things to do rather than complaining
>>>>>> about the patch headers."
>>>>>
>>>>> Hi Dooley,
>>>>>
>>>>> You are a bit off topic here sorry if you don't think this is the case but
>>>>> please do finish reading.
>>>>>
>>>>> For what the accused I will give out specific mailing dialogs to explain
>>>>> [HERE].
>>>>>
>>>>> The major discussion or query is all about the standards or rules.
>>>>> There is nothing to do with the reply.
>>>>>
>>>>> Meantime, I cannot see this as "aggressive/antagonistic responses".
>>>>> When the request changes it is ridiculous as you also agree:
>>>>> The header text /  wordings from the updated patch itself
>>>>> had zero impact on the patch itself.
>>>>>
>>>>> You are just simply telling me that if you get hit by someone 4 times,
>>>>> the man who stands out and responds is "aggressive/antagonistic".
>>>>>
>>>>> Again we are NOT discussing any mailing dialogs but the U-Boot
>>>>> patch header standards and rules.
>>>>>
>>>>> Meantime you had failed to respond or comment the entire mailing
>>>>> dialogs do mention any "---" header requirements nor the
>>>>> necessaries of following docs supreme rule / standard from first place.
>>>>>
>>>>> [HERE]
>>>>> Allow me to quote the request of header and modifications mail history:
>>>>>
>>>>> No docs cited nor clearly mentioned the need of specific wordings:
>>>>> https://patchwork.ozlabs.org/project/uboot/patch/20260420074601.24988-1-briansune@gmail.com/#3680096
>>>>>
>>>>> No docs cited nor clearly mentioned the need of specific wordings:
>>>>> https://patchwork.ozlabs.org/project/uboot/patch/20260421004719.73491-1-briansune@gmail.com/#3680232
>>>>>
>>>>> So now you are telling me after at least 2 versions of modifications
>>>>> reviewers suddenly think oh this is not good enough (by my rules)
>>>>> I think it should be other styles etc.
>>>>>
>>>>> Now "LOOK INTO MY EYES" and tell me what is the actual U-Boot
>>>>> header standard? Reviewer mood or docs that are given out?
>>>>
>>>> Brain, I understand being frustrated with the process. Ultimately,
>>>> everyone here is a volunteer and trying their best. Which means that
>>>> yes, we are not entirely consistent about some parts of the review
>>>> process. I would ask you to please be kind to everyone, and expect being
>>>> kind in return.
>>>
>>> Hi Tom,
>>>
>>> Sorry for the additional reply:
>>> First I need to apologize that I am also blinded by emotion and
>>> off-topic.
>>>
>>> Back to the topic:
>>>
>>> Patch header standard is not consistent so docs is not a
>>> supreme standard or supreme rules on the commit changes vN.
>>
>> The base rule for U-Boot is right as the beginning of the doc page:
>> ```
>> A good introduction how to prepare for submitting patches can be found in the LWN article How to Get Your Change Into the Linux Kernel as the same rules apply to U-Boot, too.
>> ```
>>
>> But as the scope of U-Boot is very different and the account of people working
>> on the project is significantly lower, so the actual review/maintainance allowance
>> is less strict.
>>
>>>
>>> Based on the above response we should conclude one fact!
>>>
>>> In those mailing pools that are citations or quotations;
>>> responses or changes requested have no inherent issue
>>> to pass and accept.
>>> The changes requested on very specific wordings are
>>> unreasonable.
>>>
>>> Of course Dooley had mentioned the request of after "---"
>>> placement however again based on this reply it should also not
>>> an issue to push to master.
>>>
>>> Again basically speaking the entire change request or requirement
>>> is not a must nor really needed in the first place.
>>>
>>> I hope this should provide a very good baseline to contributors
>>> and reviewers how they should review and create patches / commits.
>>
> 
> Hi Neil,
> 
>> The baseline is clear since most of the U-Boot developers, reviewers
>> and maintainers are experiences Linux developers as-well.
> 
> Are you sure?
> If so, why do I clearly see the double standard?
> And why Dooley would clearly mentioned doubt on the specific wordings
> making any difference.
> 
> Again without the double or multiple standards placed on the table
> and teasing with ridiculous changes requested due to specific wordings:
> why is it required to raise the tone from first place?
> 
> Reading specific dialogs is not going to understand the full picture.
> I also doubt you do read the context before reply or comment.
> 
> Meantime you are off topic on the citation of context [1] in this mail.
> My question here is pointing out double or multiple standards on specific
> wordings.

Please read my entire response instead of inventing stuff:

```
But as the scope of U-Boot is very different and the account of people working
on the project is significantly lower, so the actual review/maintainance allowance
is less strict.
```

There's no double or triple standard, there's simply a more disparate
allowance due to low review and maintenance capacity.

To make it simpler so you can understand:
We're happy when people takes time to review and pick patches, even if doesn't
strictly conform to the "rules".

Reviewing, picking, building, testing and creating pull requests takes a lot
of our precious volunteer engineering time, be grateful of that.

We're a fully volunteered, self organized open source project, please keep
this in mind.

I think this thread loops in the void, so I think it would a good time
to stop responding.

Neil

> 
> Thanks,
> Brian
> 
>>
>> And as an extent, other rules does apply informally to U-Boot like
>> any other Open Source project ran by volunteers, please have a look at:
>> https://docs.kernel.org/process/code-of-conduct.html
>>
>> I'll cite the following behaviors that any Open Source project would like
>> to have as basic rules of communication:
>> - Using welcoming and inclusive language
>> - Being respectful of differing viewpoints and experiences
>> - Gracefully accepting constructive criticism
>> - Focusing on what is best for the community
>> - Showing empathy towards other community members
>>
>> I did review the communication between You and Simon, and this exact thread,
>> and your replies are not acceptable, and I'll ask you to reconsider your tone.
>>
>> Thanks,
>> Neil
>>
>>>
>>> Thanks,
>>> Brian
>>>
>>>>
>>>> --
>>>> Tom
>>