U-Boot patch submit standard and requirement

Mon May 18 21:17:17 CEST 2026

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.

The baseline is clear since most of the U-Boot developers, reviewers
and maintainers are experiences Linux developers as-well.

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