Plan for Sunsetting MozReview

83 views
Skip to first unread message

Mark Côté

unread,
Jul 26, 2018, 2:37:57 PM7/26/18
to dev-platform, Firefox Dev
To follow up on some previous threads, here is the plan for deprecating, archiving, and decommissioning MozReview.

The MozReview shutdown deadline is approaching. Although enhanced commit-series support is still in progress (see update below), MozReview users should start familiarizing themselves with Phabricator now. We have a guide specifically for MozReview users to ease the transition (which will be updated when the commit-series work is finalized): https://moz-conduit.readthedocs.io/en/latest/mozreview-migration-guide.html

From August 6 to August 20, use of MozReview will be restricted to updates to existing reviews. In other words, review cycles in progress will be given until August 20 to be completed, but no new commit series will be permitted.

On August 20, we will remove public access to MozReview and archive patches. Every landed, in-progress, and abandoned patch will be downloaded from MozReview and stored in an S3 bucket. The “stub attachments” in Bugzilla that currently redirect to MozReview will be updated to link to the appropriate S3 bucket. Review flags and bug comments will be preserved.

After archiving is complete and verified, the MozReview servers will be decommissioned.

We will also be writing a simple redirection service to map specific MozReview reviews to associated BMO comments, review requests to associated bugs, and review-request diffs to the appropriate S3 buckets. This service will be up shortly after MozReview is decommissioned.

We realize and apologize that this is a fairly short timeline; however, the current location of the MozReview servers is in the process of being shut down, and thus it is urgent that we decommission this service soon to allow an orderly exit.

As for enhanced support for series of commits in Phabricator, the new command-line interface to submit, update, and apply series (bug 1471678) is currently in review. The first release will support Mercurial only, but git-cinnabar support will follow shortly (the code is designed with it in mind). Work on series support in Lando (bug 1457525) is progressing; we will be posting screenshots of the new UI shortly. It should be ready in 2-3 weeks.

Please note that we eventually plan to decommission Splinter as well; however, we know we need some time to work out the kinks in Phabricator. Splinter will remain operational near-term, but we ask everybody to familiarize themselves with Phabricator and file bugs when things don't work. *Please do not wait for Splinter EOL to try Phabricator; we need your feedback before then in order to act on it.*

Mark

Botond Ballo

unread,
Jul 26, 2018, 3:11:35 PM7/26/18
to Mark Côté, dev-platform, Firefox Dev
On Thu, Jul 26, 2018 at 2:37 PM, Mark Côté <mc...@mozilla.com> wrote:
> Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket.

I think I've asked this before, but plans were uncertain at the time:
will the history of patches (i.e. otherwise unpublished ancestors that
are currently stored in the MozReview repo) be archived as well?

Thanks,
Botond
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

Mark Côté

unread,
Jul 26, 2018, 3:44:46 PM7/26/18
to Botond Ballo, dev-platform, Firefox Dev
We aren't planning on archiving those to S3 buckets; that would add more complexity, since we can't just scrape Review Board for them, and from what we can tell not too many patches have unpublished historical context.

That said, and I forgot to mention this in my announcement, we'll be putting a bundle of the review repo up on S3 as well for anyone who wants to dig deeper.

Mark

Makoto Kato

unread,
Jul 26, 2018, 10:51:43 PM7/26/18
to Mark Côté, dev-platform, Firefox Dev
Mark, does you or anyone update the document [*1] for new contributors?  This MDN page still uses mozreview's way, and current mozreview document in readthedocs has exactly good for new contributors, but phabricator's document [*2] isn't good for new comer because installation steps for Windows users isn't enough (Some new contributors uses Windows according to #introduction channel of IRC).  Should we ask to MDN content team?  Of course, if arcanist is installed by ./mach bootstrap, it is no problem.


-- Makoto Kato


Mark Côté

unread,
Jul 27, 2018, 9:25:14 AM7/27/18
to Makoto Kato, dev-platform, Firefox Dev
I plan on updating a bunch of MDN docs within the next couple weeks. I agree that the Windows installation can be confusing, and yes, I'd like to package something. We're just trying to figure out the timeline for the arc-less client, but it may well be worth packaging Arcanist regardless.

Mark

Marco Bonardo

unread,
Jul 27, 2018, 9:31:12 AM7/27/18
to mc...@mozilla.com, dev-platform, m_k...@ga2.so-net.ne.jp, Firefox Dev
As a side note, the WSL terminal on Windows works properly with arc. The only downside is that you need a Windows terminal to build and a separate WSL terminal to arc diff...

Jeff Muizelaar

unread,
Jul 27, 2018, 11:00:08 AM7/27/18
to Marco Bonardo, mc...@mozilla.com, dev-platform, m_k...@ga2.so-net.ne.jp, Firefox Dev
Beware when using a WSL terminal with a Firefox source directory that
new directories created in WSL have case sensitive behaviour and this
causes cl.exe to get confused. This bit me last week.

-Jeff

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Marco Bonardo

unread,
Jul 27, 2018, 11:15:05 AM7/27/18
to Jeff Muizelaar, mc...@mozilla.com, dev-platform, m_k...@ga2.so-net.ne.jp, Firefox Dev
Thank you for the notice, I actually use WSL only for arc diff, I do everything else in the normal Windows terminal.

Mark Côté

unread,
Jul 27, 2018, 1:30:35 PM7/27/18
to dev-platform, Firefox Dev
To follow up on my follow up, there were some good suggestions on dev-platform, so we're going to amend our plan somewhat.

On August 20, we will remove public access to MozReview and move all the repositories on hg-reviewboard.mozilla.org to hg.mozilla.org (exact location TBD). We will create a simple redirection service that will map each of the following:

* review-request diff to appropriate changeset in the review repo on hg.mozilla.org
* review request to associated bug
* review to the associated BMO comment

Only diffs that have “stub attachments” will be redirected, which means the most recent diffs on review requests. This includes any abandoned or obsoleted diffs.

This will ensure that all stub attachments redirect to diffs, and that any reviewboard.mozilla.org links in docs, browser histories, etc., will redirect to equivalent content. It was also preserve any unpublished commits that were part of a diff's history.

There is no change to the update-only period from August 6 to August 20.

Mark


On Thu, Jul 26, 2018 at 2:37 PM, Mark Côté <mc...@mozilla.com> wrote:

Eric Shepherd (Sheppy)

unread,
Aug 27, 2018, 6:17:16 PM8/27/18
to Mark Côté, dev-platform, firefox-dev
We've noticed that attachment links are no longer working because they're still trying to go to reviewboard, and there don't appear to be redirects. See for example this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1211330. It has two attachments. Clicking either one of them gives you a hard-hat page instead of the changes.


_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev


--

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability

Dão Gottwald

unread,
Sep 4, 2018, 1:38:17 PM9/4/18
to Mark Côté, dev-platform, Firefox Dev
This may have been discussed before since it's kind of an obvious question:

Was there a conscious decision not to post phabricator review comments to bugzilla? It's a somewhat significant change from how we've used bugzilla. I can see a potential upside of separating review comments from other planning and chatter. Then again, the line isn't always drawn easily. Plus, it makes it harder to migrate away from phabricator should we want that at some unknown point; that MozReview posted comments to bugzilla turns out to be quite valuable now.

I'd prefer if review comments stayed in bugzilla with an option to hide them.

dao



glob

unread,
Sep 4, 2018, 11:37:12 PM9/4/18
to Dão Gottwald, Mark Côté, dev-platform, Firefox Dev

Kris Maglione

unread,
Sep 4, 2018, 11:40:39 PM9/4/18
to Dão Gottwald, Mark Côté, dev-platform, Firefox Dev
On Tue, Sep 04, 2018 at 07:37:28PM +0200, Dão Gottwald wrote:
>This may have been discussed before since it's kind of an obvious question:
>
>Was there a conscious decision not to post phabricator review comments to
>bugzilla? It's a somewhat significant change from how we've used bugzilla.
>I can see a potential upside of separating review comments from other
>planning and chatter. Then again, the line isn't always drawn easily. Plus,
>it makes it harder to migrate away from phabricator should we want that at
>some unknown point; that MozReview posted comments to bugzilla turns out to
>be quite valuable now.
>
>I'd prefer if review comments stayed in bugzilla with an option to hide
>them.

Concur. Aside from future-proofing things, reading comments in phabricator
is pretty painful, especially for bugs with multiple patches. With the old
flow, I could look at all of them in one place. Now, I have to open a half
dozen separate pages, and then scroll through the entire patch squinting for
comments, since none of the comments at the top of the review page provide
even the slightest bit of context.


--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation

Memory is like an orgasm. It's a lot better if you don't have to fake
it.
--Seymour Cray

Mark Banner

unread,
Sep 5, 2018, 2:42:32 AM9/5/18
to Kris Maglione, Mark Côté, dev-platform, Firefox Dev
On 05/09/2018 04:40, Kris Maglione wrote:
> Concur. Aside from future-proofing things, reading comments in
> phabricator is pretty painful, especially for bugs with multiple
> patches. With the old flow, I could look at all of them in one place.
> Now, I have to open a half dozen separate pages, and then scroll
> through the entire patch squinting for comments, since none of the
> comments at the top of the review page provide even the slightest bit
> of context.

A couple of things that may help with the scrolling & finding, that
people may or may not have found yet...

- You can click on the line number to the left of a comment to jump
directly to the comment.

- Once you're in the patch section of the page, there's a bar that
appears at the top. Click the "x / y comments" button and you'll be
taken straight to the next open comment and hence you can cycle through
all the open comments quickly (though it doesn't seem possible to go
through the "done" ones in this way).

Mark.

Martin Thomson

unread,
Sep 5, 2018, 3:07:33 AM9/5/18
to Mark Banner, Mark Côté, Kris Maglione, dev-platform, firefox-dev
On Wed, Sep 5, 2018 at 4:42 PM Mark Banner <mba...@mozilla.com> wrote:
> A couple of things that may help with the scrolling & finding, that
> people may or may not have found yet...

The keyboard shortcuts are more accessible (type ? to see the list
[1]), though in my experience they interact poorly with concurrent
mouse actions. One one or the other exclusively for best results.
Reply all
Reply to author
Forward
0 new messages