Agreed, we cannot and should not punish anyone. We're all volunteers here. We should operate on the honor principle. Everyone should try their best and if mistakes happen, they can be reverted.
I think Matteo's original point wasn't to set up any kind of power hierarchy, but merely to arrive at a community consensus of what conventions we agree to operate with. Just as we have the convention that we don't merge our own PRs, we can have a convention that one person doesn't dismiss another person's change request (except by a mailing list vote, in case the person who made the change request doesn't attend to it later). Oh, for clarity, the change request we're talking about is in GitHub: when you review a pull request, you can request changes. For example, if a pull request calls some API and forgets to check the return value, someone who reviews the PR can request a change to check the return value. That request for a change means that the PR should not be merged until it is fixed, or, if the PR author explains why it is correct the way it is and the reviewer agrees. For example, maybe the API is called during shutdown and the return value doesn't matter. Hope this helps, Nathan On Wed, Nov 12, 2025 at 7:59 AM Gregory Nutt <[email protected]> wrote: > Again, no one on an Apache project has any authority over anyone else. > Obviously a member with GIT write access has more power than one that is > not, but we cannot compel anyone to do anything and we cannot punish anyone > for not following rules. > > If a committed PR is harmful it can be reverted whole or in part through > another PR. > > We govern with guidelines and "peer pressure" to follow those guidelines. > There is no power hierarchy. > > I am a little confused by a change request. Is that just a problem report > via an Issue? Or are you talking about a code change. A person without > GIT write access can do whatever they choose to the change request. So can > others. There can be no punishment other than "public shaming." For PRs > that change code, the "guideline" has always been the opposite: The person > that created the PR cannot commit the without review and concurrence from > at least one other person. > > We have had the problem that this other person is a submitter's friend and > the PR is closed before world-wide community has had time to review the > change. Being world-wide, several days should elapse before resolved the > Issue or committing the PR. > ________________________________ > From: Matteo Golin <[email protected]> > Sent: Tuesday, November 11, 2025 7:41 PM > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] Dismissing PR reviews - rules > > Huh, I suppose I missed this in the guidelines! I suppose the wording with > the new proposed rule is more direct that the only person who can decide if > a change request is resolved is the person who created it. Although that > would have always been my understanding. > > Thank you for pointing this out! > > You're right, then at this point we should figure out what to do when > someone violates the rule. > > We should probably revert the PR that was merged, as a first step. But if > someone has repeatedly broken the rule, I'm not sure what a "punishment" > would be. > > I don't think there's many configuration options around these change > requests on GitHub unfortunately. I am pretty sure they stay on the PR even > after changes are pushed, I think only approvals get dismissed as stale? > I'm not certain. > > Matteo > > On Tue, Nov 11, 2025, 9:45 PM Tomek CEDRO <[email protected]> wrote: > > > On Wed, Nov 12, 2025 at 12:15 AM Alan C. Assis <[email protected]> > wrote: > > > I think it is always better to just add a comment instead of a Change > > > Request, but sometimes I put the a comment asking the change, but then > > two > > > people approve the PR, in this case I have no other option than add a > > > Change Request. > > > > > > I think this proposal is good to avoid ignoring the CR. Currently to > > merge > > > a PR all comments need to be resolved. But just like Change Request > > anyone > > > with write access can mark comments as Resolved. So Change Request is > the > > > last barrier. > > > > Yes, some changes may be even harmful, CR in that case blocks them, > > this is good behavior, and if the CR comes from a "binding" PMC member > > with a detailed explanation then it must not be canceled even after > > 72h period because this will result in vote that will be blocked by > > the "binding" vote anyway. > > > > I guess this discussion is about what to do with people who break CG > > rules right? > > > > I tired to implement github rules that would block merging with > > unresolved discussions, but when someone pushes an update the > > discussion is auto-dismissed, maybe there is a way to improve / fix > > this? > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > >
