First things first: I support that we're eventually moving to autoland
and getting rid of "manual" integration trees. I will also survive when
fx-team goes away [soonish].
However, some issues with the reasoning here...
On 13/07/2016 22:10, Gregory Szorc wrote:
> First, *I would like to encourage Firefox developers to prepare for
> the future by stopping to use fx-team*. Don't `hg pull` from fx-team:
> base your work on mozilla-central instead. Use MozReview + Autoland to
> land your commits (they will land in the integration/autoland repo).
This is not possible for all commits (*cough* security bugs *cough*). I
would really like that to get fixed, but until it does, I continue to
be, to borrow some song lyrics "stuck in the middle" between a painful
manual upload process and one I shouldn't use for the thing I'm doing.
Even where it *is* possible to use autoland, it's often just more hassle
to use autoland. Folks were surprised recently when I pointed out my
dashboards in mozreview were useless because I have hundreds and
hundreds of "open" review requests. This is why. Common situation:
1) push commits to mozreview. Get r+ with 5 nits to fix some days later
2) my tree has moved on since then. I rebase my patch onto fx-team tip,
fix the nits, hg commit --amend, replace "?" with "=" in the commit message.
Now I have two options:
a) push to fx-team
b) push to mozreview to update the patch there, then select the review
link in the terminal (painful on Windows), manually copy-paste into new
tab in web browser, hope mozreview hasn't decided to re-request any
reviews, click the small [5!] button at the top of the diff view, close
all the outstanding issues manually, click the "finish" button to
actually submit those changes if I made any comments, but even if not,
manually refresh the page because the autoland option is still going to
be greyed out (hopefully bug 1253552 is fixing this?), use UI to
autoland. This is also confusing because the issue summary of a kid
review request (e.g. https://reviewboard.mozilla.org/r/62876/
) has an
Automation entry in the top navigation bar, but the diff view (e.g.
) does not, and so I
usually spend at least some time looking for a button that's not there.
Not to be mean, but the second workflow is pretty rubbish. It takes a
lot longer and requires a lot of mousework and context switches. 3
guesses which one I therefore end up picking 90% of the time... :-)
Conversely, if I get a straight r+ with no nits, I almost always use
autoland because it's a lot less work: I open the bug with the link from
my bugmail, click the link there to go to mozreview (end up on diff view
with no automation menu), find the tiny tiny "all changes" link to go to
the parent review request, and autoland immediately from there. This
could still be a smoother process, but it's less faff than rebasing in
the terminal and pushing to fx-team (and making sure the thing I have
locally is identical to the thing I pushed to mozreview and got r+ on!).
(even there there's one more downside, though: I end up periodically
having to go through my draft csets and pruning all the ones that
already landed manually - it'd be neat if we had a mercurial extension
that could make this semi-automatic.)
Recommendations in decreasing order of effectiveness:
1) with level 3 commit access it should be possible for me to
push-to-get-this-autolanded from the commandline, much like I can push
to try. I should not need my web browser at that stage of the process.
2) don't block autoland UI in mozreview on open issues, just warn rather
than disabling it outright.
3) if hard to do, at least provide the autoland link from diff views,
and just make mozreview do the 'Hi, I'm gonna push these things'
collating all items, maybe with a big red warning if there's more than 1
cset in there.
4) provide fix/drop all remaining issues buttons on both the diff and
issue summary page
5) make navigating issues in the diff easier. Right now if I want to
resolve issues I have to manually look for the dark-blue-on-green blobs
in the side of the diff view, 'collect them all' and click "Fix"/"Drop"
in all of them (and there's no running count, so I have to go all the
way back up to the top to know if I'm done - so I never do this. Or
click the [3!] button at the top of the diff view to take me to the
"issue summary", wait ages for that page to load, and then be able to
close issues in quicker succession - but the extra page load makes this
feel slow/clunky, too.***
6) make the 'review all changes' link BIGGER. The click target is too
small, and it's in the middle of the page so it's not easy to move a
pointer to either.
> It is true you won't live on the bleeding edge. But I argue this is
> mostly a good thing because the bleeding edge gets you, well, bloody.
> Central has higher stability guarantees so you won't hit build or
> unexpected test failures as frequently (due to pulling a bad changeset
> from fx-team). If you've ever based work on a bad changeset, pushed to
> Try, and lost hours after realizing the base changeset was bad, you
> know how important stability can be.
This almost never happens on fx-team. On inbound, yes. But almost
everything that lands on fx-team is frontend-only, and so builds almost
never break, and the test results I care about are normally fine, too.
So this isn't really a big downside of fx-team IME.
> Second, I would like to hear what objections or concerns there are
> around eliminating fx-team. If fx-team goes away, your options will be
> to use Autoland (preferred) or just start using inbound instead (until
> inbound goes away, anyway - but this will be a while).
In addition to the above: stability for pushing. inbound breaks more
often so inbound is closed more often, so it's harder for me to push to
inbound than it is to fx-team.
Just generally, it feels like mozreview is full of loading indicators.
Everywhere. Even things that should just be instantaneous, like if you
click "Finish review..." first you get a "Loading..." blob, before the
dialog shows up. When the dialog shows up, then *that* has *another*
loading blob while it's collecting all the issues. The dialog should
just show up immediately - all the data it initially shows is already in
the page that's "below" the dialog, so I have no idea what it's loading
that it needed to wait for... I could sympathise with it having to fetch
issues from the network (the second "loading" blob in the dialog) but
even there it feels like it should have an optimistic cache of the data
locally so that you don't feel like you're. waiting. all. the. time.
Then if you click "Close" the dialog doesn't dismiss immediately, you
get some kind of slow fade-from-black animation. If you actually submit
a review, that gets you another "Loading..." blob but the button to
submit it isn't immediately disabled, so you can click it twice, which
leads to "interesting" "HTTP 0" (wat) errors. Generally it feels like
all the animation durations should be at least halved if not gotten rid
firefox-dev mailing list