U-Boot patch submit standard and requirement

U-Boot patch submit standard and requirement

[Sune Brian]

Hi Tom,

Sorry to bother you.

I am curious that for me myself I had no issue to follow
the requirements [1] as long as all patches that are
passing the review stage do follow the rules in [1].
However based on most recent commits and reviews
most of those are not even close to what [1] mentioned.

So at the end, reviewers in U-Boot just made their own
standard and requested contributors to follow?

Rather the U-Boot itself should all follow the docs rules?

[1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions

Thanks,
Brian

Re: U-Boot patch submit standard and requirement

[Peter Robinson]

Hi Brian,

Can you provide more context?

Peter

On Thu, 14 May 2026 at 03:02, Sune Brian <briansune@gmail.com> wrote:
>
> Hi Tom,
>
> Sorry to bother you.
>
> I am curious that for me myself I had no issue to follow
> the requirements [1] as long as all patches that are
> passing the review stage do follow the rules in [1].
> However based on most recent commits and reviews
> most of those are not even close to what [1] mentioned.
>
> So at the end, reviewers in U-Boot just made their own
> standard and requested contributors to follow?
>
> Rather the U-Boot itself should all follow the docs rules?
>
> [1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
>
> Thanks,
> Brian

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Thu, May 14, 2026 at 3:29 PM Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Hi Brian,
>
> Can you provide more context?

Hi Peter,

Not getting you sorry.
Context means?

Thanks,
Brian

>
> Peter
>
> On Thu, 14 May 2026 at 03:02, Sune Brian <briansune@gmail.com> wrote:
> >
> > Hi Tom,
> >
> > Sorry to bother you.
> >
> > I am curious that for me myself I had no issue to follow
> > the requirements [1] as long as all patches that are
> > passing the review stage do follow the rules in [1].
> > However based on most recent commits and reviews
> > most of those are not even close to what [1] mentioned.
> >
> > So at the end, reviewers in U-Boot just made their own
> > standard and requested contributors to follow?
> >
> > Rather the U-Boot itself should all follow the docs rules?
> >
> > [1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
> >
> > Thanks,
> > Brian

Re: U-Boot patch submit standard and requirement

[Peter Robinson]

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.

Ultimately the rules are there as guidance and if someone chooses not
to follow them to the letter there is little that can be done. if the
individual becomes problematic they will be asked, publicly or
privately depending on the situation, if they could better comply and
there may be further action.

It's very hard to act on your generic statement without examples,.

Peter

On Thu, 14 May 2026 at 09:41, Sune Brian <briansune@gmail.com> wrote:
>
> On Thu, May 14, 2026 at 3:29 PM Peter Robinson <pbrobinson@gmail.com> wrote:
> >
> > Hi Brian,
> >
> > Can you provide more context?
>
> Hi Peter,
>
> Not getting you sorry.
> Context means?
>
> Thanks,
> Brian
>
> >
> > Peter
> >
> > On Thu, 14 May 2026 at 03:02, Sune Brian <briansune@gmail.com> wrote:
> > >
> > > Hi Tom,
> > >
> > > Sorry to bother you.
> > >
> > > I am curious that for me myself I had no issue to follow
> > > the requirements [1] as long as all patches that are
> > > passing the review stage do follow the rules in [1].
> > > However based on most recent commits and reviews
> > > most of those are not even close to what [1] mentioned.
> > >
> > > So at the end, reviewers in U-Boot just made their own
> > > standard and requested contributors to follow?
> > >
> > > Rather the U-Boot itself should all follow the docs rules?
> > >
> > > [1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
> > >
> > > Thanks,
> > > Brian

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Thu, May 14, 2026 at 6:37 PM Peter Robinson <pbrobinson@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

Quoting message [A]:

- The required format is 'Changes in vN:'. Custom formats such as
   'Changelog vN -> vN+1:' are not acceptable.

Now quoting those examples that don't follow this supreme rule.

Example 1: Reviewed without any change requests as [A] complained
also aginsted [1] supreme standard
https://patchwork.ozlabs.org/project/uboot/patch/20260508-qcom_spl-v6-1-aaac1ab17b50@seznam.cz/

Example 2: Reviewed without any change requests as [A] complained
also aginsted [1] supreme standard
https://patchwork.ozlabs.org/project/uboot/patch/20260513015606.591384-2-rs@ti.com/

Example 3: Reviewed without any change requests as [A] complained
also aginsted [1] supreme standard and even "Accepted Stage"
https://patchwork.ozlabs.org/project/uboot/patch/BESP194MB2805271AD5DBE47B322F8DC3DA3A2@BESP194MB2805.EURP194.PROD.OUTLOOK.COM/

Example 4: Reviewed without any change requests as [A] complained
also aginsted [1] supreme standard and even "Accepted Stage"
https://patchwork.ozlabs.org/project/uboot/patch/20260511144437.46645-1-james.hilliard1@gmail.com/

If you want more examples I can keep listing but I think this is more
than enough.

Well in order one t o follow the rules other should do the same.
Under such bases I have no issue however I cannot see this is
the real case.

Enjoy!
Brian

>
> Ultimately the rules are there as guidance and if someone chooses not
> to follow them to the letter there is little that can be done. if the
> individual becomes problematic they will be asked, publicly or
> privately depending on the situation, if they could better comply and
> there may be further action.
>
> It's very hard to act on your generic statement without examples,.
>
> Peter
>
> On Thu, 14 May 2026 at 09:41, Sune Brian <briansune@gmail.com> wrote:
> >
> > On Thu, May 14, 2026 at 3:29 PM Peter Robinson <pbrobinson@gmail.com> wrote:
> > >
> > > Hi Brian,
> > >
> > > Can you provide more context?
> >
> > Hi Peter,
> >
> > Not getting you sorry.
> > Context means?
> >
> > Thanks,
> > Brian
> >
> > >
> > > Peter
> > >
> > > On Thu, 14 May 2026 at 03:02, Sune Brian <briansune@gmail.com> wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > Sorry to bother you.
> > > >
> > > > I am curious that for me myself I had no issue to follow
> > > > the requirements [1] as long as all patches that are
> > > > passing the review stage do follow the rules in [1].
> > > > However based on most recent commits and reviews
> > > > most of those are not even close to what [1] mentioned.
> > > >
> > > > So at the end, reviewers in U-Boot just made their own
> > > > standard and requested contributors to follow?
> > > >
> > > > Rather the U-Boot itself should all follow the docs rules?
> > > >
> > > > [1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
> > > >
> > > > Thanks,
> > > > Brian

Re: U-Boot patch submit standard and requirement

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 5263 bytes --]

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@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/

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.

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.

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.

Cheers,
Conor.

> 
> Quoting message [A]:
> 
> - The required format is 'Changes in vN:'. Custom formats such as
>    'Changelog vN -> vN+1:' are not acceptable.
> 
> Now quoting those examples that don't follow this supreme rule.
> 
> Example 1: Reviewed without any change requests as [A] complained
> also aginsted [1] supreme standard
> https://patchwork.ozlabs.org/project/uboot/patch/20260508-qcom_spl-v6-1-aaac1ab17b50@seznam.cz/
> 
> Example 2: Reviewed without any change requests as [A] complained
> also aginsted [1] supreme standard
> https://patchwork.ozlabs.org/project/uboot/patch/20260513015606.591384-2-rs@ti.com/
> 
> Example 3: Reviewed without any change requests as [A] complained
> also aginsted [1] supreme standard and even "Accepted Stage"
> https://patchwork.ozlabs.org/project/uboot/patch/BESP194MB2805271AD5DBE47B322F8DC3DA3A2@BESP194MB2805.EURP194.PROD.OUTLOOK.COM/
> 
> Example 4: Reviewed without any change requests as [A] complained
> also aginsted [1] supreme standard and even "Accepted Stage"
> https://patchwork.ozlabs.org/project/uboot/patch/20260511144437.46645-1-james.hilliard1@gmail.com/
> 
> If you want more examples I can keep listing but I think this is more
> than enough.
> 
> Well in order one t o follow the rules other should do the same.
> Under such bases I have no issue however I cannot see this is
> the real case.
> 
> Enjoy!
> Brian
> 
> >
> > Ultimately the rules are there as guidance and if someone chooses not
> > to follow them to the letter there is little that can be done. if the
> > individual becomes problematic they will be asked, publicly or
> > privately depending on the situation, if they could better comply and
> > there may be further action.
> >
> > It's very hard to act on your generic statement without examples,.
> >
> > Peter
> >
> > On Thu, 14 May 2026 at 09:41, Sune Brian <briansune@gmail.com> wrote:
> > >
> > > On Thu, May 14, 2026 at 3:29 PM Peter Robinson <pbrobinson@gmail.com> wrote:
> > > >
> > > > Hi Brian,
> > > >
> > > > Can you provide more context?
> > >
> > > Hi Peter,
> > >
> > > Not getting you sorry.
> > > Context means?
> > >
> > > Thanks,
> > > Brian
> > >
> > > >
> > > > Peter
> > > >
> > > > On Thu, 14 May 2026 at 03:02, Sune Brian <briansune@gmail.com> wrote:
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > Sorry to bother you.
> > > > >
> > > > > I am curious that for me myself I had no issue to follow
> > > > > the requirements [1] as long as all patches that are
> > > > > passing the review stage do follow the rules in [1].
> > > > > However based on most recent commits and reviews
> > > > > most of those are not even close to what [1] mentioned.
> > > > >
> > > > > So at the end, reviewers in U-Boot just made their own
> > > > > standard and requested contributors to follow?
> > > > >
> > > > > Rather the U-Boot itself should all follow the docs rules?
> > > > >
> > > > > [1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
> > > > >
> > > > > Thanks,
> > > > > Brian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Fri, May 15, 2026 at 12:14 AM Conor Dooley <conor@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@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 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.

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

Regards,
Brian

> Cheers,
> Conor.
>
> >
> > Quoting message [A]:
> >
> > - The required format is 'Changes in vN:'. Custom formats such as
> >    'Changelog vN -> vN+1:' are not acceptable.
> >
> > Now quoting those examples that don't follow this supreme rule.
> >
> > Example 1: Reviewed without any change requests as [A] complained
> > also aginsted [1] supreme standard
> > https://patchwork.ozlabs.org/project/uboot/patch/20260508-qcom_spl-v6-1-aaac1ab17b50@seznam.cz/
> >
> > Example 2: Reviewed without any change requests as [A] complained
> > also aginsted [1] supreme standard
> > https://patchwork.ozlabs.org/project/uboot/patch/20260513015606.591384-2-rs@ti.com/
> >
> > Example 3: Reviewed without any change requests as [A] complained
> > also aginsted [1] supreme standard and even "Accepted Stage"
> > https://patchwork.ozlabs.org/project/uboot/patch/BESP194MB2805271AD5DBE47B322F8DC3DA3A2@BESP194MB2805.EURP194.PROD.OUTLOOK.COM/
> >
> > Example 4: Reviewed without any change requests as [A] complained
> > also aginsted [1] supreme standard and even "Accepted Stage"
> > https://patchwork.ozlabs.org/project/uboot/patch/20260511144437.46645-1-james.hilliard1@gmail.com/
> >
> > If you want more examples I can keep listing but I think this is more
> > than enough.
> >
> > Well in order one t o follow the rules other should do the same.
> > Under such bases I have no issue however I cannot see this is
> > the real case.
> >
> > Enjoy!
> > Brian
> >
> > >
> > > Ultimately the rules are there as guidance and if someone chooses not
> > > to follow them to the letter there is little that can be done. if the
> > > individual becomes problematic they will be asked, publicly or
> > > privately depending on the situation, if they could better comply and
> > > there may be further action.
> > >
> > > It's very hard to act on your generic statement without examples,.
> > >
> > > Peter
> > >
> > > On Thu, 14 May 2026 at 09:41, Sune Brian <briansune@gmail.com> wrote:
> > > >
> > > > On Thu, May 14, 2026 at 3:29 PM Peter Robinson <pbrobinson@gmail.com> wrote:
> > > > >
> > > > > Hi Brian,
> > > > >
> > > > > Can you provide more context?
> > > >
> > > > Hi Peter,
> > > >
> > > > Not getting you sorry.
> > > > Context means?
> > > >
> > > > Thanks,
> > > > Brian
> > > >
> > > > >
> > > > > Peter
> > > > >
> > > > > On Thu, 14 May 2026 at 03:02, Sune Brian <briansune@gmail.com> wrote:
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > Sorry to bother you.
> > > > > >
> > > > > > I am curious that for me myself I had no issue to follow
> > > > > > the requirements [1] as long as all patches that are
> > > > > > passing the review stage do follow the rules in [1].
> > > > > > However based on most recent commits and reviews
> > > > > > most of those are not even close to what [1] mentioned.
> > > > > >
> > > > > > So at the end, reviewers in U-Boot just made their own
> > > > > > standard and requested contributors to follow?
> > > > > >
> > > > > > Rather the U-Boot itself should all follow the docs rules?
> > > > > >
> > > > > > [1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
> > > > > >
> > > > > > Thanks,
> > > > > > Brian

Re: U-Boot patch submit standard and requirement

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3913 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Fri, May 15, 2026 at 3:46 PM Conor Dooley <conor.dooley@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@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@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?

Regards,
Brian

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

Re: U-Boot patch submit standard and requirement

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6325 bytes --]

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@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@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@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Fri, May 15, 2026 at 11:02 PM Tom Rini <trini@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@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@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@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,

First  appreciate the reply.

Of course being kind and expecting the same returns is fair and even.
However, being kind and returning with teasing on the requirements
considered as appropriate action?

Then simply charge the teased unit or units with unkind behavior?
Again I had given out rooms and kindnesses from first place, however the
return is not as even as you had described.
Of course you can 100% recap it as me who shows unkindness on
the table by "verbally".
Without the double standards or even multi standards are being
shown on the table, why do I act unkindly in the first place?

Simple logic:

for(int i=0;i<standards;i++){
kind = ture;
if(reviewers_mood == you_shall_not_pass)
return teasing_func();
}

void teasing_func(void){
int bottom_line = false;
while(1){
bottom_line  = infinite_sta_bottom_line_trigger();
if(bottom_line){
kind = false;
return done_with_you();
}
}
}

Fair enough =]

Cheers,
Brian

>
> --
> Tom

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Fri, May 15, 2026 at 11:02 PM Tom Rini <trini@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@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@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@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.

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.

Thanks,
Brian

>
> --
> Tom

Re: U-Boot patch submit standard and requirement

[Neil Armstrong]

On 5/16/26 01:11, Sune Brian wrote:
> On Fri, May 15, 2026 at 11:02 PM Tom Rini <trini@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@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@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@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

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Tue, May 19, 2026 at 3:17 AM Neil Armstrong
<neil.armstrong@linaro.org> wrote:
>
> On 5/16/26 01:11, Sune Brian wrote:
> > On Fri, May 15, 2026 at 11:02 PM Tom Rini <trini@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@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@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@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.

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
>

Re: 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@linaro.org> wrote:
>>
>> On 5/16/26 01:11, Sune Brian wrote:
>>> On Fri, May 15, 2026 at 11:02 PM Tom Rini <trini@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@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@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@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
>>

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Tue, May 19, 2026 at 3:06 PM Neil Armstrong
<neil.armstrong@linaro.org> wrote:
>
> On 5/19/26 00:05, Sune Brian wrote:
> > On Tue, May 19, 2026 at 3:17 AM Neil Armstrong
> > <neil.armstrong@linaro.org> wrote:
> >>
> >> On 5/16/26 01:11, Sune Brian wrote:
> >>> On Fri, May 15, 2026 at 11:02 PM Tom Rini <trini@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@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@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@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.
>

Hi Neil,

> Please read my entire response instead of inventing stuff:

First I read your comments.
Second, hold your horses and ask if you really understand the entire context?
Third I did not "invent stuff" which I also suggest you check your tone. This is
a serious accusation.


Allow me to help you a bit:

Quote:
https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3684415

According to what you mentioned, it is less strict, however from what
it described
does this follow what you had mentioned?

While after that there are several patches that the same reviewer
does not necessarily need the specific wordings to accept.

I just understand as normally when the citation clearly mentioned a
distinctively strict standard for commit; suddenly other patches
did not follow the same standard / rules on the same group of reviewers?

When two review standards are shown to the same reviewer how can you
describe this? Isn't this considered a double standard?

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

If so why specifically alarmingly tell the specific docs section from
first place.
As well as making strong phrases that specific wordings are not passing the
standard of ....

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

I will suggest you read the gpl 2.0 license give and take on both sides!

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

Same story, different sides, aren't contributors  working under the same
bases?

Now you describe it as such:
due to the volunte actions you have all rights to bully, tease, act
like a tyrant
on whatever the passing line defines.

I plan to stop in the first place as Tom had nicely answered my question.
Quentin gave out why and what was missing to do it properly in the first place.
Dooley agreed with the harsh wordings where it simply made zero differences.

Where any constructive comments are very welcome as well as long
reading the full story rather than jumping to conclusions.

My goal or my original question just query on the specific wordings are
necessary or not. Nothing to do with the tone nor the reply dialogs.

However once describing the tones; all people jumped out. You should
change your tone etc.

Well, aren't we living in a "causal system"!
Without those standards, guidelines, and rules plus various variants
in the first place I will not give out a strong tone!
Meantime, when telling specific unity with one rule and another
to other unities this simply represented as being targeting.
Clearly displaying double standard either you gave out slacks on the
first place or what Quentin mentioned, strict patch format maybe with very
little slack.
While doing both well this crealy introduces other thoughts.

Again appreciate all the work on all parties.
So if you are still happy to comment / reply feel free to do so.
There is no doubt that same reviewer two different stories on reviewing
thing.

Best wishes,
Brian

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

Re: U-Boot patch submit standard and requirement

[Quentin Schulz]

Hi Brian,

On 5/14/26 3:51 AM, Sune Brian wrote:
> Hi Tom,
> 
> Sorry to bother you.
> 
> I am curious that for me myself I had no issue to follow
> the requirements [1] as long as all patches that are
> passing the review stage do follow the rules in [1].
> However based on most recent commits and reviews
> most of those are not even close to what [1] mentioned.
> 
> So at the end, reviewers in U-Boot just made their own
> standard and requested contributors to follow?
> 
> Rather the U-Boot itself should all follow the docs rules?
> 
> [1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
> 

If you feel like other people's patches aren't properly formatted 
according to the docs, you have two options:

- review them on the mailing list and tell them to follow the format as 
specified in the docs, like Simon did for your patch,
- suggest updates (or send patches!) to the docs to better match what is 
followed by the project,
- if they aren't about the commit log, you can send follow-up patches to 
fix the source code to better match what we document, (but you cannot on 
commit logs as those cannot be modified once merged),

If you do not understand why someone is requesting changes, ask them to 
explain or point at the documentation. If you disagree with the reasons, 
you can *politely* tell them that by providing arguments. However, 
maintainers are free to go the "agree-to-disagree" way and refuse your 
patch. You have to work with them to get your patches merged, sometimes 
it means being really patient.

Maintainers are famously overworked in any open-source project you can 
think of. By following the rules (which sometimes are implicit), you 
make their life (and the life of reviewers) easier as it's less effort 
for them to review as it follows some patterns they are used to.

Maintainers are people, like you, like me, they also make mistakes or 
give some leeway because it's the 15th version of a patch and required 
changes aren't worth going back and forth with the contributor. This is 
the *maintainer*'s call, and they're free to decide to do it for one 
patch of one person or not. It's a fallacy to say "this patch didn't 
follow a rule and got merged so I'll not follow this rule". At that 
point, why even write a commit log? Why even have comments? Why even 
care about the code compiling without warnings? Why care about security 
holes in the patch since other patches got merged with security issues?

I've learned over the years to not answer when I'm getting angry because 
someone doesn't understand what I'm writing or they have unreasonable 
requests. You wait a few hours, or a few days, and you read again the 
mail with a cold head and you usually read with a different perspective 
and you can now stay polite with them (and sometimes you understand what 
you wrote was confusing because it could be understood another way). 
Getting angry, especially at maintainers, will be a sure way to get 
people to ignore you. Since they are not your colleagues they perfectly 
can decide they don't want to work with you. Yes, it's unfair.

Remember also that people are not in your head, so providing context in 
your patches or emails is really important. The more information and 
context you can provide, the less the person reading your mail will have 
to think or guess before they can review your patch.

For example:

- 8f41874f4631 ("fix socfpga GEN5 handoff script path"). When was src 
variable removed? If I had reviewed that patch, I would have looked for 
a commit that removed that variable and it may not be obvious so it'll 
take me time that you likely have already spent yourself.
- bb1c2b463265 ("update GCC version check after Kbuild bump"). What 
errors did you see? Did you test any other toolchain than GCC 10.0.1?
- 5b1fe6ef6b81 ("Altera SoCFpga Boot Stall Fix"). Where does it stops in 
the boot process? What's the boot log? "After testing", what kinds of 
tests? There's no explanation as to *why* this patch works, only that 
it's imported from downstream fork from Altera (that you say is 
"official"). I can understand this as "I don't understand what this is 
doing but it works", which some maintainers may accept, some may not.
- e291277689f6 ("sync socfpga common u-boot dts". The Device Tree node 
would be present in U-Boot proper. So the issue is that you're missing 
L2 and memory controllers in xPL stages. Why is it important? What kind 
of issues does it fix?
- 3ba9b1f7bd7e ("Cyclone V Board handsoff script"). No explanation as 
what this does. Why is it better than the current implementation? What 
does it bring? From which version of "official" downstream fork of 
Altera did you import this script?
- 1feebc36e588 ("FPGA2SDRAM setup fix"). When does it stall? What's the 
symptom? What are the bootlogs? What is stalling "from distro"? "This 
patch fix the issue", but why/how? This sounds like "I tried something 
and it worked, I don't understand why" which we typically do not like.

Were *I* maintainer, I would have accepted none of those patches in that 
form and instead asked you to provide more information. By not providing 
information, you're stripping users the ability to figure out if an 
issue they experience in an older U-Boot has been fixed in newer 
versions without having to compile the new version and testing by 
themselves. They could just look at commit logs (or do a search on the 
Internet since our mailing list is publicly archived) and see if someone 
had the same issue and it was patched. This is *not* a theoretical 
benefit, it happens often in the Linux kernel. With additional 
information, it helps us figuring out if we can refactor or remove code 
a few years from now because we could hope to reproduce the problem you 
fixed and see if it's still fixed after refactoring/deleting code. All 
that to say, your patches also benefited from not exactly following 
rules. An obvious one being (specifically the last sentence):

"""
Keep EVERY line under 72 characters. That is, your message should be 
line-wrapped with line-feeds. However, don’t get carried away and wrap 
it too short either since this also looks funny.
"""

They also do not adhere (according to me; see the list of questions I 
would have had on now-merged commits) to:

"""
Detail level: The audience of the commit log message that you should 
cater to is those familiar with the underlying source code you are 
modifying, but who are _not_ familiar with the patch you are submitting. 
They should be able to determine what is being changed and why.
"""

I've noted multiple times that your patches typically do not follow the 
naming scheme where there could at least be one prefix like "socfpga: ", 
c.f.:

"""
If applicable, prefix the summary line with a word describing what area 
of code is being affected followed by a colon. This is a standard 
adopted by both U-Boot and Linux. [...] The best thing to do is look at 
the “git log <file>” output to see what others have done so you don’t 
break conventions.
"""

Though to be fair, some merged socfpga patches don't and it's not always 
easy to find an appropriate prefix. For 
arch/arm/mach-socfpga/misc_gen5.c, it could have been "arm: socfgpa: ". 
For arch/arm/config.mk, "arch: arm: " or "arch: arm: build:" for 
example. For cmd/Kconfig, "cmd: " at the very least. For the new boards, 
something like "arm: socfpga: " for example. This is important because 
people visually filter what they want to review or not. After looking 
into your patch submissions in the past, I understood that you mostly do 
stuff related to socfpga which I have no interested in, but since the 
commit titles don't match what I'm expecting, I now simply ignore all 
your patches even though I could and likely would have reviewed 
f26db83ca964 ("fix PL330 CMD supported target") and bb1c2b463265 
("update GCC version check after Kbuild bump").

Cheers,
Quentin

Re: U-Boot patch submit standard and requirement

[Sune Brian]

Hi Quentin,

You replied with a long passage.
No worries, I finished reading it.

On Tue, May 19, 2026 at 2:29 AM Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Brian,
>
> On 5/14/26 3:51 AM, Sune Brian wrote:
> > Hi Tom,
> >
> > Sorry to bother you.
> >
> > I am curious that for me myself I had no issue to follow
> > the requirements [1] as long as all patches that are
> > passing the review stage do follow the rules in [1].
> > However based on most recent commits and reviews
> > most of those are not even close to what [1] mentioned.
> >
> > So at the end, reviewers in U-Boot just made their own
> > standard and requested contributors to follow?
> >
> > Rather the U-Boot itself should all follow the docs rules?
> >
> > [1] https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
> >
>
> If you feel like other people's patches aren't properly formatted
> according to the docs, you have two options:

First I had no intention to step into someone's shoes.
My intention or goal here is pointing out a double standard
on a single patch by the same group of reviewers.
Again no intention on pointing to specific people or persons.

>
> Maintainers are famously overworked in any open-source project you can
> think of. By following the rules (which sometimes are implicit), you
> make their life (and the life of reviewers) easier as it's less effort
> for them to review as it follows some patterns they are used to.

Agree, so in order to follow or change at least as possible why not
quote the docs or requirements or even give out examples in the first place?
And rather rephrasing yourself in various standards along the same
patch version?
I guess this is not a schizophrenia behavior right?
Also I would consider such behavior as teasing behavior.

>
> Maintainers are people, like you, like me, they also make mistakes or
> give some leeway because it's the 15th version of a patch and required
> changes aren't worth going back and forth with the contributor. This is
> the *maintainer*'s call, and they're free to decide to do it for one
> patch of one person or not. It's a fallacy to say "this patch didn't
> follow a rule and got merged so I'll not follow this rule". At that
> point, why even write a commit log? Why even have comments? Why even
> care about the code compiling without warnings? Why care about security
> holes in the patch since other patches got merged with security issues?

Agree that human form indeed.
If the same person works on the same review mindset, with my quoted
patches how could it even possible that there will be different
standards when reviewing or passing patches that alarmingly mentioned on
one patch that the format wordings should be xxxx?
I cannot tell this is done by mistake nor not worthy in the first place of
standard who mentioned specifically.

>
> I've learned over the years to not answer when I'm getting angry because
> someone doesn't understand what I'm writing or they have unreasonable
> requests. You wait a few hours, or a few days, and you read again the
> mail with a cold head and you usually read with a different perspective
> and you can now stay polite with them (and sometimes you understand what
> you wrote was confusing because it could be understood another way).
> Getting angry, especially at maintainers, will be a sure way to get
> people to ignore you. Since they are not your colleagues they perfectly
> can decide they don't want to work with you. Yes, it's unfair.

For this it is not unfair to me and it is perfectly fair.
Meantime I have no anger in this first place. I explained on the reply and
had done what you also mentioned at the end of this reply. By xxx reasons
I am going to ignore your mail etc. Why bother?

>
> Remember also that people are not in your head, so providing context in
> your patches or emails is really important. The more information and
> context you can provide, the less the person reading your mail will have
> to think or guess before they can review your patch.

Agree! So this works on both not only one side but both sides right?
Why not cite the docs or provide examples or even explain better from
first place on review in order contributors know what is the standard.
Reviewers expect someone to correct something and with expected
standards so laid down necessary info for it.

>
> For example:
>
> - 8f41874f4631 ("fix socfpga GEN5 handoff script path"). When was src
> variable removed? If I had reviewed that patch, I would have looked for
> a commit that removed that variable and it may not be obvious so it'll
> take me time that you likely have already spent yourself.
> - bb1c2b463265 ("update GCC version check after Kbuild bump"). What
> errors did you see? Did you test any other toolchain than GCC 10.0.1?
> - 5b1fe6ef6b81 ("Altera SoCFpga Boot Stall Fix"). Where does it stops in
> the boot process? What's the boot log? "After testing", what kinds of
> tests? There's no explanation as to *why* this patch works, only that
> it's imported from downstream fork from Altera (that you say is
> "official"). I can understand this as "I don't understand what this is
> doing but it works", which some maintainers may accept, some may not.
> - e291277689f6 ("sync socfpga common u-boot dts". The Device Tree node
> would be present in U-Boot proper. So the issue is that you're missing
> L2 and memory controllers in xPL stages. Why is it important? What kind
> of issues does it fix?
> - 3ba9b1f7bd7e ("Cyclone V Board handsoff script"). No explanation as
> what this does. Why is it better than the current implementation? What
> does it bring? From which version of "official" downstream fork of
> Altera did you import this script?
> - 1feebc36e588 ("FPGA2SDRAM setup fix"). When does it stall? What's the
> symptom? What are the bootlogs? What is stalling "from distro"? "This
> patch fix the issue", but why/how? This sounds like "I tried something
> and it worked, I don't understand why" which we typically do not like.
>
> Were *I* maintainer, I would have accepted none of those patches in that
> form and instead asked you to provide more information. By not providing

Good why not do so, if this is really doing U-Boot benefit?

> information, you're stripping users the ability to figure out if an
> issue they experience in an older U-Boot has been fixed in newer
> versions without having to compile the new version and testing by
> themselves. They could just look at commit logs (or do a search on the
> Internet since our mailing list is publicly archived) and see if someone
> had the same issue and it was patched. This is *not* a theoretical
> benefit, it happens often in the Linux kernel. With additional
> information, it helps us figuring out if we can refactor or remove code
> a few years from now because we could hope to reproduce the problem you
> fixed and see if it's still fixed after refactoring/deleting code. All
> that to say, your patches also benefited from not exactly following
> rules. An obvious one being (specifically the last sentence):

I am not sure I follow you here but I will try.
I am not sure how other reviewers work their code. At least I work on real
hardware no virtual or even without real hardware testing.
At the end of the day U-Boot is to serve not display so real hardware
functioning is the goal.
At least this could trigger maintainers to investigate or confidently reply this
is not the case.


>
> """
> Keep EVERY line under 72 characters. That is, your message should be
> line-wrapped with line-feeds. However, don’t get carried away and wrap
> it too short either since this also looks funny.
> """
>
> They also do not adhere (according to me; see the list of questions I
> would have had on now-merged commits) to:
>
> """
> Detail level: The audience of the commit log message that you should
> cater to is those familiar with the underlying source code you are
> modifying, but who are _not_ familiar with the patch you are submitting.
> They should be able to determine what is being changed and why.
> """
>
> I've noted multiple times that your patches typically do not follow the
> naming scheme where there could at least be one prefix like "socfpga: ",
> c.f.:
>
> """
> If applicable, prefix the summary line with a word describing what area
> of code is being affected followed by a colon. This is a standard
> adopted by both U-Boot and Linux. [...] The best thing to do is look at
> the “git log <file>” output to see what others have done so you don’t
> break conventions.
> """
>
> Though to be fair, some merged socfpga patches don't and it's not always
> easy to find an appropriate prefix. For
> arch/arm/mach-socfpga/misc_gen5.c, it could have been "arm: socfgpa: ".
> For arch/arm/config.mk, "arch: arm: " or "arch: arm: build:" for
> example. For cmd/Kconfig, "cmd: " at the very least. For the new boards,
> something like "arm: socfpga: " for example. This is important because
> people visually filter what they want to review or not. After looking
> into your patch submissions in the past, I understood that you mostly do
> stuff related to socfpga which I have no interested in, but since the
> commit titles don't match what I'm expecting, I now simply ignore all
> your patches even though I could and likely would have reviewed
> f26db83ca964 ("fix PL330 CMD supported target") and bb1c2b463265
> ("update GCC version check after Kbuild bump").

Ok the last part of the reply said why you ignore my patches and
propose the title naming etc.
Again do those have a docs or page that people could reference to?
Or can a reviewer simply mark it as change requests and reply one
sentence i.e. missing proper patch group title reference [1] to correct etc?

At least this reply is really constructive on pointing out what the issue
rather than teasing on the header wordings.

Thanks for the suggestions.

Bests,
Brian

>
> Cheers,
> Quentin

Re: U-Boot patch submit standard and requirement

[Quentin Schulz]

Hi Brian,

What I understood as being your complaints are the following:

1. you were told to put the version changelog in your patch to match the 
expected format. You did it in the next version but not the way we 
expected it. You were asked a second time to reformat your changelog to 
adhere to the expected format, with a more precise guideline. A second 
answer then provided you with the link to the documentation.

Appropriate links are
https://patchwork.ozlabs.org/project/uboot/patch/20260421004719.73491-1-briansune@gmail.com/#3680205
https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3683491
https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3684415

The requests made by Simon (reviewer) and Tien Fong (maintainer) are 
valid as this is explained in details in the docs. See 
https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions 
where you also have an example. However, I see the requests for 
"'Changes in vN:' rather than 'Changelog vN -> vN+1:'" as nitpicks. I'm 
almost certain neither Simon nor Tien Fong would have requested you to 
change that if it was the only thing to complain about. It's just that 
the changelog being part of the commit log is an issue, and since you'll 
likely need to send another version to fix that, "oh by the way, also 
try to do this while at it" happened. It's not unusual. If it was the 
only feedback, I would have understood the frustration.

The second and third links do NOT invalidate what had been said in the 
first one. There was a misunderstanding because there was room for 
misunderstanding. I understand the request made by Simon in the first 
mail could have resulted in the patch you sent, which doesn't match the 
expected format. Nobody's fault here, misunderstandings happen all the 
time. We make things clearer in subsequent versions of the patch or 
discuss them. I do not consider what Simon did as being hostile. If 
something is unclear, you can always ask for clarification.

I will also note that Simon took the time to better explain the rule a 
second time once the misunderstanding was detected and to provide a link 
to the documentation.

I will join Neil here and tell you that the phrasing in
https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3683515 
and 
https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3684100 
is unacceptable towards Simon.

Additionally, dismissing Simon's comments simply because he's a reviewer 
and not a maintainer is not the solution. The project relies on 
reviewers because maintainers do not have the time to review each and 
every version of the patch. We put trust in reviewers so that the work 
load is lighter on maintainers (and hopefully, with more eyes, we miss 
fewer bugs).

2. you feel like you were victim of a double standard because reviewers 
didn't complain about missing or misformated changelog from other 
contributors.

Provided (by you) links are
https://patchwork.ozlabs.org/project/uboot/patch/20260508-qcom_spl-v6-1-aaac1ab17b50@seznam.cz/
https://patchwork.ozlabs.org/project/uboot/patch/20260513015606.591384-2-rs@ti.com/
https://patchwork.ozlabs.org/project/uboot/patch/BESP194MB2805271AD5DBE47B322F8DC3DA3A2@BESP194MB2805.EURP194.PROD.OUTLOOK.COM/
(and some others)

First, there are some patches for which Simon (or Tien Fong, who shared 
Simon's opinion on changelog formatting) didn't participate in.

Second, your examples sometimes are patch series which do have a cover 
letter where the changelog is mentioned. They do not appear on patchwork 
(but they do on the mailing list). See 
https://lore.kernel.org/u-boot/20260508-qcom_spl-v6-0-aaac1ab17b50@seznam.cz/ 
and lore.kernel.org/u-boot/20260513015606.591384-1-rs@ti.com/. Yes we 
have inconsistencies here. Simon has complained in the past with 
changelog per-patch being better (for him) than changelog per-series 
(i.e. in the cover-letter). Having *some* is good enough for the project 
is what we decided on.

Third, you cannot cherry-pick a single patch version and say "look here 
nobody said anything", later patch versions may receive feedback like 
you had, earlier versions may have received feedback that wasn't taken 
into account (this should not happen, but mistakes happen). Usually, 
once a patch or two gets feedback that something warrants another 
version, reviewers and maintainers pay less attention to the patch 
series as we know we'll have another version to look at in a few days/weeks.

Fourth, different reviewers and maintainers are different people. They 
have their own rules, either stricter, or more lax. It may also depend 
on the reviewer or maintainer mood at the time. You cannot hold Simon 
and Tien Fong responsible for another reviewer or maintainer not telling 
another contributor to follow rules.

If you want to name that multistandard, then yes, we have that. It's 
sometimes desired (not every maintainer wants to apply the same rules 
with the same strictness as others, that's their right as a maintainer), 
sometimes not ("oops, we merged something too quick and forgot to check 
all the rules"). But I don't believe we're applying the multistandard to 
someone in particular. If this happens, please bring this up as I'm 
pretty sure this is not something we want to see happening.

If there are things we can automate or document better, then please 
consider sending patches to improve the situation.


As an aside, I'm not a native speaker and we may be coming from 
different cultures, so this might explain why I'm reading most of your 
mails as being aggressive, dismissive and sometimes plain rude. I 
understand it can be a language barrier, but please remember that we 
have a somewhat diverse community where people come from different 
cultures and different levels of understanding of the English language 
so what may be rude or not rude to you may be received differently by 
people reading you (and vice-versa).

As personal anecdote, I still cringe when I remember participating on 
some forums when I was 14 and thinking "bullshit" was an okay synonym 
for "a lie" or a simple difference of opinion, I cannot imagine how the 
other people felt when reading me back then.

I'll finish by saying that sometimes it's easier to spin a new version 
than arguing or getting angry, even if I slightly disagree with the 
reviewer or maintainer. It's better for my health and it's less 
time-consuming. Picking one's battles is not an easy task :)

Cheers,
Quentin

Re: U-Boot patch submit standard and requirement

[Sune Brian]

On Tue, May 19, 2026 at 8:45 PM Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Brian,
>
> What I understood as being your complaints are the following:
>
> 1. you were told to put the version changelog in your patch to match the
> expected format. You did it in the next version but not the way we
> expected it. You were asked a second time to reformat your changelog to
> adhere to the expected format, with a more precise guideline. A second
> answer then provided you with the link to the documentation.
>

Hi Quentin,

I learn from you and understand the kindness here.
But sorry that from what your quotation shows:
That's why I am very sure everybody from this email pool
have not read all the context from beginning to end.

First the mentioning of change versioning not started at v4:
Read this ->
https://patchwork.ozlabs.org/project/uboot/patch/20260420074601.24988-1-briansune@gmail.com/#3680096

Second, I never complained about the needs for specific requirements
either strict nor slack!

Third, I would follow without any issue as long as there is good info
and minimum redoing it again and again due to the inherent bad
instructions that are being laid down.

Four, I gave at least 3 versions of modification options changes with
comments either agreeing to disagree yet following reviewer suggestions
as first priority.


> Appropriate links are
> https://patchwork.ozlabs.org/project/uboot/patch/20260421004719.73491-1-briansune@gmail.com/#3680205
> https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3683491
> https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3684415
>
> The requests made by Simon (reviewer) and Tien Fong (maintainer) are
> valid as this is explained in details in the docs. See
> https://docs.u-boot.org/en/latest/develop/sending_patches.html#sending-updated-patch-versions
> where you also have an example. However, I see the requests for
> "'Changes in vN:' rather than 'Changelog vN -> vN+1:'" as nitpicks. I'm
> almost certain neither Simon nor Tien Fong would have requested you to
> change that if it was the only thing to complain about. It's just that
> the changelog being part of the commit log is an issue, and since you'll
> likely need to send another version to fix that, "oh by the way, also
> try to do this while at it" happened. It's not unusual. If it was the
> only feedback, I would have understood the frustration.

No you did not! Because I expected people who mentioning rules and standards
are perfectly crystal clear on delivering the necessary correction to whom it
request to follow.

>
> The second and third links do NOT invalidate what had been said in the
> first one. There was a misunderstanding because there was room for
> misunderstanding. I understand the request made by Simon in the first
> mail could have resulted in the patch you sent, which doesn't match the
> expected format. Nobody's fault here, misunderstandings happen all the
> time. We make things clearer in subsequent versions of the patch or
> discuss them. I do not consider what Simon did as being hostile. If
> something is unclear, you can always ask for clarification.

I again clearly speak out my mind clearly.
I never intended to use an inappropriate tone in the first place!
However if you request me the change one specific things do it properly
by good context at least less than three times.
Again the context which going to correct also be reasonable and
really what it meant rather than oh I think this is not my standard
strictly changing it and alarmly pointing it is creating a git am issue.

>
> I will also note that Simon took the time to better explain the rule a
> second time once the misunderstanding was detected and to provide a link
> to the documentation.

Again it is not second rather even considered as fourth.

>
> I will join Neil here and tell you that the phrasing in
> https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3683515
> and
> https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3684100
> is unacceptable towards Simon.
>
> Additionally, dismissing Simon's comments simply because he's a reviewer
> and not a maintainer is not the solution. The project relies on
> reviewers because maintainers do not have the time to review each and
> every version of the patch. We put trust in reviewers so that the work
> load is lighter on maintainers (and hopefully, with more eyes, we miss
> fewer bugs).
>
> 2. you feel like you were victim of a double standard because reviewers
> didn't complain about missing or misformated changelog from other
> contributors.
>
> Provided (by you) links are
> https://patchwork.ozlabs.org/project/uboot/patch/20260508-qcom_spl-v6-1-aaac1ab17b50@seznam.cz/
> https://patchwork.ozlabs.org/project/uboot/patch/20260513015606.591384-2-rs@ti.com/
> https://patchwork.ozlabs.org/project/uboot/patch/BESP194MB2805271AD5DBE47B322F8DC3DA3A2@BESP194MB2805.EURP194.PROD.OUTLOOK.COM/
> (and some others)
>
> First, there are some patches for which Simon (or Tien Fong, who shared
> Simon's opinion on changelog formatting) didn't participate in.
>
> Second, your examples sometimes are patch series which do have a cover
> letter where the changelog is mentioned. They do not appear on patchwork
> (but they do on the mailing list). See
> https://lore.kernel.org/u-boot/20260508-qcom_spl-v6-0-aaac1ab17b50@seznam.cz/
> and lore.kernel.org/u-boot/20260513015606.591384-1-rs@ti.com/. Yes we
> have inconsistencies here. Simon has complained in the past with
> changelog per-patch being better (for him) than changelog per-series
> (i.e. in the cover-letter). Having *some* is good enough for the project
> is what we decided on.
>
> Third, you cannot cherry-pick a single patch version and say "look here
> nobody said anything", later patch versions may receive feedback like

This is because that patch involved some area that I also intended to fix on
and the patch had been rejected and handed off to Alif.
Meantime, the reason is because it is reviewed by T.F. and also very good
example to feedback to whom that the original alarming is absolutely
unnecessary.

> you had, earlier versions may have received feedback that wasn't taken
> into account (this should not happen, but mistakes happen). Usually,
> once a patch or two gets feedback that something warrants another
> version, reviewers and maintainers pay less attention to the patch
> series as we know we'll have another version to look at in a few days/weeks.
>
> Fourth, different reviewers and maintainers are different people. They
> have their own rules, either stricter, or more lax. It may also depend
> on the reviewer or maintainer mood at the time. You cannot hold Simon
> and Tien Fong responsible for another reviewer or maintainer not telling
> another contributor to follow rules.
>
> If you want to name that multistandard, then yes, we have that. It's
> sometimes desired (not every maintainer wants to apply the same rules
> with the same strictness as others, that's their right as a maintainer),
> sometimes not ("oops, we merged something too quick and forgot to check
> all the rules"). But I don't believe we're applying the multistandard to
> someone in particular. If this happens, please bring this up as I'm
> pretty sure this is not something we want to see happening.
>
> If there are things we can automate or document better, then please
> consider sending patches to improve the situation.
>
>
> As an aside, I'm not a native speaker and we may be coming from
> different cultures, so this might explain why I'm reading most of your
> mails as being aggressive, dismissive and sometimes plain rude. I
> understand it can be a language barrier, but please remember that we
> have a somewhat diverse community where people come from different
> cultures and different levels of understanding of the English language
> so what may be rude or not rude to you may be received differently by
> people reading you (and vice-versa).
>
> As personal anecdote, I still cringe when I remember participating on
> some forums when I was 14 and thinking "bullshit" was an okay synonym
> for "a lie" or a simple difference of opinion, I cannot imagine how the
> other people felt when reading me back then.
>
> I'll finish by saying that sometimes it's easier to spin a new version
> than arguing or getting angry, even if I slightly disagree with the

That's why I mentioned dropping this patch and I will do the next
action before understanding the full picture why and how could
reviewers review in such a manner.

> reviewer or maintainer. It's better for my health and it's less
> time-consuming. Picking one's battles is not an easy task :)

Well with all said I only point back to an example that T.F. review
and applied what he mentioned to me as alarmingly not going to
pass the U-Boot system so why not mentioning during the code fix
etc.

Again I never write to pinpoint down to a specific person or persons.
But just finding an appropriate balance on slack and strictness.
However what I saw or experienced is unable to do so.

Again this mail pool is asking why and how the rules are being applied.
Meantime I also did not complain about any of those quotations in the
first place.
While Peter expects a full context citation to follow what is the actual
situation here, so I had no choice to quote it and make life easier in
the first place.

I never complain about anything but just seeking an answer to the
standard and rules on patch reviewing and commision.

I guess this is more than enough to explain my original question.
Meantime I appreciate all the efforts on explanations and referencing
back to my patch mistakes.

Thanks,
Brian

>
> Cheers,
> Quentin

Re: U-Boot patch submit standard and requirement

[Sune Brian]

Hi Quentin,

Just one follow up!

> where you also have an example. However, I see the requests for
> "'Changes in vN:' rather than 'Changelog vN -> vN+1:'" as nitpicks. I'm
> almost certain neither Simon nor Tien Fong would have requested you to
> change that if it was the only thing to complain about. It's just that
> the changelog being part of the commit log is an issue, and since you'll
> likely need to send another version to fix that, "oh by the way, also
> try to do this while at it" happened. It's not unusual. If it was the
> only feedback, I would have understood the frustration.

https://patchwork.ozlabs.org/project/uboot/patch/20260423042824.3480-1-briansune@gmail.com/#3684415

"I have reviewed this patch.

While the functional change appears reasonable, the patch cannot be
applied in its current form because the commit message and version
history do not follow U-Boot patch submission conventions. Specifically:

- Per-version change history must be placed below the '---' separator.
- The required format is 'Changes in vN:'. Custom formats such as
   'Changelog vN -> vN+1:' are not acceptable.

Maintainers rely on these conventions so patches can be applied directly
using git am without manual rework. I will not correct the commit history
on behalf of the contributor.

Please resend the patch with the commit message formatted correctly.
Further review or application will only proceed once this requirement is
met.

Best regards,

Tien Fong"

Well I have no idea how you can intercept:
"you'll likely need to send another version to fix that"

BTW I think this is my final reply.

Agree or disagree doesn't matter, at least I know the true story here.

Thank you,
Brian

> Cheers,
> Quentin