Same -1 here as in the other thread ("Branch protection rules
(CTR-style)"), see Emanual and Phil's comments:From: Emmanuel Bourg <[email protected]> ... On 01/11/2025 22:16, Phil Steitz wrote: > +1 to Gary's -1. Same for me, let's keep things simple, Commons has enough processes. Gary On Mon, Nov 3, 2025 at 2:28 PM Piotr P. Karwasz <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
