On Tue, May 19, 2026 at 3:06 PM Neil Armstrong <[email protected]> wrote: > > On 5/19/26 00:05, Sune Brian wrote: > > On Tue, May 19, 2026 at 3:17 AM Neil Armstrong > > <[email protected]> wrote: > >> > >> On 5/16/26 01:11, Sune Brian wrote: > >>> On Fri, May 15, 2026 at 11:02 PM Tom Rini <[email protected]> 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 > >>>>> <[email protected]> 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 <[email protected]> > >>>>>>> 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 > >>>>>>>>> <[email protected]> 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/[email protected]/#3684415 > >>>>>>>> > >>>>>>>> patchwork isn't loading for me, but it's on lore here: > >>>>>>>> https://lore.kernel.org/all/[email protected]/ > >>>>>>>> > >>>>>>> > >>>>>>> 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/[email protected]/#3680232 > >>>>>>> > >>>>>>> https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > >>>>>>> > >>>>>>> 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+kokoj...@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_ujjnwshahdm...@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/[email protected]/#3680096 > >>>>> > >>>>> No docs cited nor clearly mentioned the need of specific wordings: > >>>>> https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/#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/[email protected]/#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 > >> >
