Hi Mark, On 29.10.2025 13:18, Mark Thomas wrote: > This is a major increase in overhead for trivial fixes. > > The Jakarta EE spec projects all use this and it increases the time > taken for trivial fixes by about an order of magnitude. > > It certainly isn't going to encourage me to push trivial fixes I make in > the Tomcat forks upstream.
My concern with so-called “trivial” fixes is this: - What is trivial for the author may not be trivial for others. For example, many native English speakers overlook the complexity of case folding and localization issues, which can introduce subtle bugs. - “Trivial” changes can unintentionally include non-trivial modifications. - Saying a change is trivial often implies “trust me, this is correct”. But reviews are not about trust, they are about reducing the probability of human error. That’s why I review trivial changes with the same attention as any other. - Trivial fixes are frequently split into multiple small commits, which can actually increase cognitive load for reviewers and make changes easier to overlook. In practice, “trivial” fixes increase the burden on reviewers if we take review seriously, and they increase the risk that errors slip through because they are treated casually. Personally, I prefer to batch documentation or Javadoc fixes into a feature branch and review them together before release, especially since tools (e.g. Copilot) can help verify that no unintended code changes are included. If a change is truly trivial, either: 1. it has no real impact on behavior, or 2. it can be reproduced automatically using a tool, which the reviewer can then use to verify it easily. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
