Yes, to be clear, I don't think there should or can be a punishment. I was expressing my confusion with that statement in the current contribution guide. Everyone is a volunteer and it's hard to punish volunteers! And it doesn't seem right to punish them either.
I just want some clarity on a rule about dismissing feedback to merge and what the procedure should be if that happens (i.e. revert the PR). On Wed, Nov 12, 2025, 9:10 AM Tomek CEDRO <[email protected]> wrote: > On Wed, Nov 12, 2025 at 2:22 PM Nathan Hartman <[email protected]> > wrote: > > 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. > > Yes, just as Alan mentioned this is kind of github PR handling process > to say "I do not agree yet to merge it in this form and changes needs > to be made before merge to upstream is done". > > What Matteo talks about is situation where some committers ignore this > Change Request and merge to upstream anyway because github allows to > somehow overcome this rule / mechanism. I think this should be > implemented on the per-repo rules basis just as we have other > mechanisms implemented :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
