On Feb 15, 2013, at 1:11 AM, Tyler Romeo <[email protected]> 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 | [email protected] > 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
