> One thing is to challenge things.
> If the rules are set in a way that rc1+ gets only Bugfixes
So it's not ok to challenge things like the substance of rules...
So it's not ok to challenge things like the substance of rules...
The proper way here would have been two pull requests, one with all the bugfixes, and one with the new feature with a cover letter motivating why an exception should happen. And if this happens often enough with sufficiently good backing motivations, then he may be able to convince people.
I have had a similar experience with a team member who was quietly unhappy about a rule. Instead of raising a discussion about the rule (like the rest of the team members did) he tried to quietly ignore it in his work, usually via requesting reviews from less stringent reviewers.
As a result, after a while I started documenting every single instance of his sneaky rule-breakage, sending every instance straight to his manager, and the person was out pretty soon.
It is directly challenged in the very thread linked in the article (and likely before, the drama is ancient).
Also, there is no "less stringent reviewer", it's always been the same you!
So your example fails at both core points, yet your outcome is still the same happy firing!
At least for paid work you can just sprinkle $ to cover up such mistakes and find someone else, but wait, this is also not paid work!
Linux caught Kent when he tried to sneak in non-bugfixes into a RC, and berated him.
After that (not before, this is a critical distinction) Kent said "I don't want to abide by the rules, because I have my concerns".
This is very similar to the situation I have described, except that in Linux it was Linus who was skipping reviews on Kent's code trusting him not to subvert the rules, and in situation I described the team collectively was trusting each other not to subvert the rules.
Except one person.