On Feb 15, 2013, at 1:11 AM, Tyler Romeo <tylerromeo(a)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(a)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