On Feb 15, 2013, at 1:11 AM, Tyler Romeo tylerromeo@gmail.com wrote:
I know this is pretty obvious, but self-merging pretty much any change should be grounds for removal (or at the very least no second chance).
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Though certain repositories in Gerrit have their own policies (such as operations, who appears to use Git mostly as a log, they self-merge continuously, maybe even after deployment - don't know if that's the case)
But I agree that for MediaWiki core self-merging needs to be frowned upon more. I don't know if revoking access should be a directly correlated consequence though, that may be too extreme.
Note though that there are at least 2 commonly accepted exceptions:
* Backporting a change approved by someone else in master to another branch, and self-merging that backport
e.g. User A pushes for review to master, User B approves it and merges it, User A or User C then pushes the same change to another branch and self-merges that) - such as to REL branches or WMF branches.
* Reverting
Due to the way Git and Gerrit interact, a revert (unlike a merge) is a two-step process. It considers it to be a separate commit (which it is, of course). So clicking Revert only drafts a commit, it still needs to be merged. This is generally done straight away if the revert reason comes from someone with merge rights.
These 2 cases (and maybe more, such as i18n-bot) were the reasons that a few weeks/months back we didn't make the change in Gerrit to make self-merging no longer an option (e.g. reject merge attempts by the author of the change).
-- Krinkle