Hi, On 3.11.2025 18:24, Elliotte Rusty Harold wrote: > On Mon, Nov 3, 2025 at 2:53 PM Emmanuel Bourg <[email protected]> wrote: > >> Commit != Release >> >> If the commit wasn't reviewed when pushed it will be reviewed during the >> release discussion. > > Unlikely. Commons releases usually go forward with only one person > (the releaser) paying any attention at all, and I doubt that person > makes a point of looking at what's actually changed in the code. Maybe > that person looks at the commit messages, sometimes. Maybe they get > lucky and notice if something is off, but probably not.
I agree. In Commons, only our benevolent release manager has detailed knowledge of the changes included in a release. The cumulative understanding of the rest of the PMC often doesn’t cover the full set of commits. In theory, everything should be fine as long as all commits are reviewed before a release, but how does that work in practice? Let’s take the Commons Compress 1.26.0 release [1] as an example: - Elliotte’s comments during the vote were largely dismissed because the release addressed security vulnerabilities. - About six months later, Emmanuel reverted the additions of `commons- codec` [3] and `commons-lang3` [4], receiving a -1. Technically, such objections could have been raised when those dependencies were first introduced, but no one noticed at the time. Supply chain security is increasingly important to our users, and emerging standards such as SLSA 1.2 [5] define clear criteria for source code integrity. At the highest level (SLSA Source L4), every change must be reviewed by two trusted individuals. It’s hard to imagine that organizations aiming for SLSA Source L4 compliance will be comfortable depending on libraries that cannot demonstrate a comparable level of review. Therefore, I see two possible paths forward: 1. Stick with CTR, but make sure every commit *actually* gets reviewed before it ends up on a protected branch. That’s tricky, since there aren’t really tools to enforce it. We could, for example, protect the `release` branch and require a PR from `master` before doing a release. The review, however, would be not very thorough. 2. Switch to RTC, protect `master`, and make sure each batch of commits gets reviewed properly, but without slowing things down too much. I believe we have enough active PMC members to handle this so-called “Byzantine bureaucracy” without increasing Gary’s workload. What do you think? Piotr [1] https://lists.apache.org/thread/5vtbbs18d4rntn8tpnpsvo0g9h6svc30 [2] https://lists.apache.org/thread/91r4rgqwjv64hy3g5cdjhwhwbjfcc983 [3] https://lists.apache.org/thread/v4vrzz7zq4o7qd21t9nfhpdqxshvb8g7 [4] https://lists.apache.org/thread/lt4bbfsncph0mzzcww18ggopfdgv3yg1 [5] https://slsa.dev/spec/v1.2-rc1/source-requirements --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
