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/

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.
(...)

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

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?