U-Boot patch submit standard and requirement

[Conor Dooley]

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."

> > Also, your responses to Simon in the thread you link are very
> > aggressive and antagonistic. Please try to be kinder to those that take
> > time to review your submissions.
> >
-------------- 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/09aa354a/attachment.sig>