U-Boot patch submit standard and requirement

Fri May 15 17:02:27 CEST 2026

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260515/7ffa02be/attachment.sig>