Page MenuHomePhabricator

Align basics of current Gerrit code-review process with Differential
Closed, DeclinedPublic

Description

We have a code review process that works in Gerrit, and we need to have a code review process with the same spirit that works in Phabricator.

Let's identify the points that Phabricator can cover already today with a proper configuration, and let's create subtasks to discuss the points that seem to be currently unsupported.

The current process, abstracted (edits welcome!)

  1. Project ownership
    • Individual owners are members of groups. Group "foo" is the owner of Git repository "foo".
    • Meta-groups can join groups in order to simplify membership management. For instance, the meta-group "fundraising" is member of each group for each of their repositories.
      • yep, in owners via teams (which can be restricted)
    • Only the owners of a group (and the admins) can accept new owners for that group. (The creator of a repository is automatically its owner?)
      • they're called ACL policies in Differential/Phabricator
    • Inheritance can can be set up. For example, permissions for mediawiki/extensions inherit from mediawiki, and permissions for mediawiki/extensions/GuidedTour inherit from mediawiki/extensions.
  2. Code review
    • Owners are the only ones that can accept or reject revisions (+2 / -2). No revision gets through without the acceptance of one member of the owners group related to that repository.
      • Yep, the owners are the ones with push access to the repo (like in Gerrit)
    • Self-merges are discouraged but they are technically possible.
      • Yep, and we even have Audit to catch them/review them if the repository owners want to
    • All users can comment and recommend or discourage the acceptance of a revision (+1 / -1). Non-owners have no means to accept a revision.
      • Same as Gerrit
    • Currently an update on a revision resets the recommendations collected except for -2 votes (unless it is a trivial rebase (same diff, different parent) or change only in the summary (ie: no code change)).
      • configurable with differential.sticky-accept
    • A Jenkins bot reviews all revisions; it will reject them if they don't pass the criteria.
    • A localization bot gets their revisions automatically accepted in all repositories.

Details

Reference
fl274

Related Objects

Event Timeline

flimport raised the priority of this task from to High.
flimport set Reference to fl274.

scfc wrote on 2014-05-02 15:27:32 (UTC)

@Qgil: What do you mean by the latter part of: "(There is an ongoing discussion about the possibility to keep recommendations for minor changes, maybe this would be superseded by local linting?)"

qgil wrote on 2014-05-02 15:50:11 (UTC)

http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/76733 , but now I see that it is not an ongoing discussion anymore. Quoting @hashar:

Gerrit knows about two different trivial changes:

  • trivial rebase: the new patchset is the same diff but the parent has changed. This is often fine but the new patch my not be working anymore. Though if that happens tests will catch it.
  • no code change: only the commit summary has changed. Ie the proposed code is exactly the same and should have the same behavior.

Details:

https://gerrit.wikimedia.org/r/Documentation/config-labels.html#label_copyAllScoresOnTrivialRebase

cscott wrote on 2014-05-02 16:11:05 (UTC)

I also find the fact that a change is exactly a commit in gerrit is a *good* thing. Phabricator adds a lot of "power" --- which results in a lot of confusion. Gerrit's primary benefit was that it was built around the git model, more or less exactly. There's no semantic overlap/confusion.

qchris wrote on 2014-05-02 16:24:49 (UTC)

I also find the fact that a change is exactly a commit in gerrit is a *good* thing.

Me too.

qgil wrote on 2014-05-06 00:47:39 (UTC)

@hashar and @demon believe that we can adapt Phabricator to our code review process, probably requiring additional time and some changes/improvements upstream. Both also believe that the code review side of Phabricator shouldn't stop the task/bug management, where we have enough content and challenges to fulfill a first phase that will deprecate Bugzilla, RT, Mingle, and Trello.

This opinion (that I also share) has been reflected in the Phabricator RfC draft plan. Later this week, I will move this task together with T229 and T47 to "Not critical for the RfC", unless someone has a better idea.

Nemo_bis wrote on 2014-07-24 00:39:41 (UTC)

A Jenkins bot is the first reviewer of all revisions; it will reject them if they don't pass the criteria.

I don't understand this. Is commenting frozen until a jenkins bot reviews, so that it's always first?

Revi wrote on 2014-07-24 02:45:05 (UTC)

In T274#25, @Nemo_bis wrote:

A Jenkins bot is the first reviewer of all revisions; it will reject them if they don't pass the criteria.

I don't understand this. Is commenting frozen until a jenkins bot reviews, so that it's always first?

Maybe you're looking for https://www.mediawiki.org/w/index.php?title=Continuous_integration%2FWorkflow ?

hashar wrote on 2014-07-24 08:41:10 (UTC)

In T274#25, @Nemo_bis wrote:

A Jenkins bot is the first reviewer of all revisions; it will reject them if they don't pass the criteria.

I don't understand this. Is commenting frozen until a jenkins bot reviews, so that it's always first?

Basically means Jenkins will whine whenever the tests fails.

mmodell wrote on 2014-07-24 09:03:06 (UTC)

@cscott and @QChris:

FWIW, there is no reason we can't use a workflow very similar to what we have with gerrit. And arcanist certainly supports the squashed-commit model where a differential essentially can map to one commit, in fact that used to be the default behaviour and is the current behaviour inside Facebook AFAIK.

Nemo_bis wrote on 2014-08-01 18:45:41 (UTC)

Basically means Jenkins will whine whenever the tests fails.

Ok, so "first" was unintended specification. It's clearer now with Matt's edit. http://fab.wmflabs.org/transactions/detail/PHID-XACT-TASK-rntjyf3rzqywtpb/

Qgil renamed this task from The code review process in Differential/Audit needs to be adapted to our needs to Align Wikimedia and Phabricator code review processes .
Qgil set Security to None.
Qgil lowered the priority of this task from High to Normal.Oct 20 2014, 10:35 PM
Qgil lowered the priority of this task from Normal to Low.Nov 27 2014, 8:21 AM
Qgil added a subscriber: Qgil.
jayvdb added a subscriber: jayvdb.Dec 5 2014, 1:28 AM
bd808 added a subscriber: bd808.
Qgil added a comment.Aug 25 2015, 9:19 PM

For what is worth, https://secure.phabricator.com/T182#133871

The primary upstream goal behind this feature is establishing a chain of custody for changes, such that no single engineer can make changes on their own without going through the review process.
Right now, review is advisory and non-binding. An engineer can make changes to their code between the time it is reviewed and when it lands without restriction: we don't enforce that what was reviewed was exactly what was pushed, and the code which is pushed can be wholly different than what was reviewed.
(...)

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 25 2015, 9:19 PM
cscott added a subscriber: cscott.Sep 17 2015, 8:49 PM
greg moved this task from To Triage to Tooling on the Gerrit-Migration board.Dec 2 2015, 12:25 AM
greg raised the priority of this task from Low to Normal.
greg moved this task from Tooling to Social on the Gerrit-Migration board.Mar 15 2016, 10:59 PM
greg updated the task description. (Show Details)May 13 2016, 5:40 PM
greg added a subscriber: greg.

(I just quickly responded to the various points in the descriptions with answers or tasks.)

greg renamed this task from Align Wikimedia and Phabricator code review processes to Align basics of current Gerrit code-review process with Differential.May 13 2016, 5:42 PM
Qgil awarded a token.May 13 2016, 8:00 PM
greg updated the task description. (Show Details)Jul 2 2016, 12:00 AM

Inheritance can can be set up. For example, permissions for mediawiki/extensions inherit from mediawiki, and permissions for mediawiki/extensions/GuidedTour inherit from mediawiki/extensions.

Would mediawiki/extensions/GuidedTour also inherit permissions from mediawiki or just mediawiki/extensions?

Mholloway edited subscribers, added: Mholloway; removed: Mhollo.May 22 2017, 1:57 PM
demon closed this task as Declined.Mar 7 2018, 10:12 PM
demon added a subscriber: demon.