<div dir="ltr"><div>I'd like to fifth the concern about patch series. Mercurial+MozReview encourage a very healthy culture or building patch series, rebasing them, absorbing new changes into existing stack and pushing to review.</div><div><br></div><div>I cannot imagine not being able to use this as the default workflow, and quite frankly, I'd be even concern if the default behavior of the new system incentivized different behavior from the patch author and reviewers.</div><div><br></div><div>On top of that there are several features that MozReview either has, or lacks, that I think are important for this transition to be perceived as an improvement:</div><div><br></div><div> - interdiff in mozreview is lackluster. Rebased patchsets mess with the interdiff, which incentivizes not rebasing while working on a patchset, or removes the reviewers ability to use the interdiff.<br></div><div> - it's critically important that I can set r? on multiple people, they can pass it on between each other, and once they r+ the r+ stays. I've had multiple cases where MozReview somehow erased the r+ from someone and I had to r+ it myself on behalf of them which got then rejected due to the lack of whitelisted reviewer...<br></div><div> - feedback flag is very useful in building the culture of asking for it early and clearly communicating the stage of the patch and evaluation requested out of a person. MozReview not only doesn't have it, but also happily erases f? flags set on the patches in bugzilla. [2]<br></div><div> - Patchsets in MozReview are very individual, while software engineering is cooperative. Two scenarios where it clashes:</div><div> - I write a patchset, and someone writes one more patch that should be added to it. Currently they have to submit it to bugzilla, I'll add it to my patchset, and submit it as my patch. [1]<br></div><div> - :mossop writes a patchset, and I'm taking over. Instead of being able to push an updated revision of the patchset, I'm pushing a new patchset which obsoletes mossop's one. There's no way for anyone to understand what I changed. [2]<br></div><div><br></div><div>I understand that we're customizing existing software, which makes it harder to make it fit our use cases perfectly. And I trust the team that this is a better long term solution, but I'd like us to recognize that we are a project of truly unique scale. There are very, very few projects that operate on similar number of patches, have similar number of contributors, lines of code, technologies and stacks.</div><div><br></div><div>I'd dare to say that our project is in 1% of the most complex open source projects, and bugzilla/mozreview/lando/phabricator are crucial for our ability to continue developing it. The fact that GitHub doesn't handle some use case and it's ok for them, doesn't mean we can afford skipping it.</div><div><br></div><div>So, without asking for all the bells and whistles now, I'd like to express a hope that the plan is to continue bringing whistles rather than trying to mold our developer cycle to fit some apps feature set.<br></div><div><br></div><div>zb.<br></div><div><br></div><div>[1] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1457021">https://bugzilla.mozilla.org/show_bug.cgi?id=1457021</a><br></div><div>[2] <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1455649">https://bugzilla.mozilla.org/show_bug.cgi?id=1455649</a><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 6, 2018 at 10:31 PM Mike Hommey <<a href="mailto:mh@glandium.org">mh@glandium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 07, 2018 at 01:16:05PM +0800, glob wrote:<br>
> i would create a stack of revisions, as per<br>
> <a href="https://smacleod.ca/posts/commit-series-with-phabricator/" rel="noreferrer" target="_blank">https://smacleod.ca/posts/commit-series-with-phabricator/</a><br>
> <br>
> this won't squash the commits, and is extremely close to the commit series<br>
> we know and love in mozreview. there are ergonomics that need to be worked<br>
> on (particularly around landing a stack) which are already on the roadmap[1]<br>
> as the next thing our team will be focusing on.<br>
<br>
FWIW, I like how it is simple to push stuff to mozreview. Even if that<br>
doesn't go well across rebases for the interdiffs, it is<br>
straightforward. It seems like phabricator, on that level, puts us in a<br>
worse situation than what we had with plain bugzilla (where scripts<br>
exist to push multi-commits as separate attachments).<br>
<br>
ISTR phabricator was supposed to get support to a "push to a repo"<br>
workflow, and I would have been fine with that, but having to use a PHP<br>
cli for an experience worse than what we had before mozreview is really<br>
not attractive.<br>
<br>
Mike<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote></div>