On Tue, May 19, 2026 at 8:45 PM Quentin Schulz <[email protected]> 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/[email protected]/#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/[email protected]/#3680205 > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/#3683491 > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/#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/[email protected]/#3683515 > and > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/#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/[email protected]/ > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > https://patchwork.ozlabs.org/project/uboot/patch/besp194mb2805271ad5dbe47b322f8dc3da...@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/[email protected]/ > and lore.kernel.org/u-boot/[email protected]/. 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
