Plan for Sunsetting MozReview

[Mark Côté]

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]

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

[Mark Côté]

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

[Karl Tomlinson]

Mark Côté writes:

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

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

Could the stub attachments and review-request diffs (but not
interdiffs of course) redirect to the commits in the review repo
(at https://reviewboard-hg.mozilla.org/gecko/ or wherever this
ends up), please?

The parent revision is important to the meaning of a patch, and
it is not clear that navigation from the S3 buckets to the
mercurial revisions in the review repo will be easy.

[Mark Côté]

The problem there is that the review repo will be bundled and stored. We
don't want to run another Mercurial server indefinitely. Although, if the
parent is a public changeset (as I believe most are), we could put a link
to that commit in mozilla-central somewhere.

Mark

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

[Mike Hommey]

On Thu, Jul 26, 2018 at 06:31:34PM -0400, Mark Côté wrote:
> The problem there is that the review repo will be bundled and stored. We
> don't want to run another Mercurial server indefinitely. Although, if the
> parent is a public changeset (as I believe most are), we could put a link
> to that commit in mozilla-central somewhere.

Does it need to be "another mercurial server", though? It could be
moved to hg.mozilla.org, under some archive hierarchy or something.
Or its heads could be added to try (for the gecko mozreview repo).

Mike

[Makoto Kato]

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

*1
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_Get_your_code_reviewed
*2 http://moz-conduit.readthedocs.io/en/latest/phabricator-user.html

On Fri, Jul 27, 2018 at 3:37 AM, Mark Côté <mc...@mozilla.com> wrote:

> 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
>
>

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

[Mark Côté]

I talked to gps, and yes, we can totally do that.

Mark

[Mark Côté]

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

On Thu, Jul 26, 2018 at 10:18 PM, Makoto Kato <m_k...@ga2.so-net.ne.jp>
wrote:

[Marco Bonardo]

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]

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

[Marco Bonardo]

Thank you for the notice, I actually use WSL only for arc diff, I do
everything else in the normal Windows terminal.

On Fri, Jul 27, 2018 at 4:41 PM Jeff Muizelaar <jmuiz...@mozilla.com>
wrote:

[Mark Côté]

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

[Eric Shepherd (Sheppy)]

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 <https://freebusy.io/eshe...@mozilla.com>

[gsqu...@mozilla.com]

(Disclaimer: I'm not from IT!)

Until this gets fixed, a workaround for closed bugs is to go to the bottom of the bug, and look for https://hg.mozilla.org/mozilla-central/rev/... links.
Not as pretty, and missing review context, but hopefully this should help explore the changed code in most cases.

Cheers,
Gerald

On Tuesday, August 28, 2018 at 8:17:24 AM UTC+10, Eric Shepherd (Sheppy) wrote:
> 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.
>

> Eric Shepherd

[Botond Ballo]

> Until this gets fixed, a workaround for closed bugs is to go to the bottom of the bug, and look for https://hg.mozilla.org/mozilla-central/rev/... links.
> Not as pretty, and missing review context, but hopefully this should help explore the changed code in most cases.

For bugs that aren't closed, or where you specifically want to look at
an older revision than the one that landed, you can also query the
review repo for all revisions associated with a bug:

https://hg.mozilla.org/mozreview/gecko/log?rev=<bugnumber>

(assuming the bug number is present in the commit message).

Hope that helps!

Botond

[Mark Côté]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1480887 for the redirect
service, which is in progress.

Mark

On Mon, Aug 27, 2018 at 6:57 PM, Botond Ballo <bba...@mozilla.com> wrote:

> > Until this gets fixed, a workaround for closed bugs is to go to the
> bottom of the bug, and look for https://hg.mozilla.org/
> mozilla-central/rev/... links.
> > Not as pretty, and missing review context, but hopefully this should
> help explore the changed code in most cases.
>

> For bugs that aren't closed, or where you specifically want to look at
> an older revision than the one that landed, you can also query the
> review repo for all revisions associated with a bug:
>
> https://hg.mozilla.org/mozreview/gecko/log?rev=<bugnumber>
>
> (assuming the bug number is present in the commit message).
>
> Hope that helps!
>
> Botond

[glob]

Dão Gottwald wrote on 5/9/18 1:37 am:
> This may have been discussed before since it's kind of an obvious
> question:
https://groups.google.com/forum/#!msg/mozilla.dev.platform/V1vuWPeD_hc/d-hio96ZAwAJ
https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/e3Pi-_FpBgAJ
https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/tsF7UfxvBgAJ
> 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
>
>
>
> 2018-07-26 20:37 GMT+02:00 Mark Côté <mc...@mozilla.com
> <mailto:mc...@mozilla.com>>:

> firef...@mozilla.org <mailto:firef...@mozilla.org>
> https://mail.mozilla.org/listinfo/firefox-dev
> <https://mail.mozilla.org/listinfo/firefox-dev>

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

--

glob — engineering workflow — moz://a

[Kris Maglione]

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.

>2018-07-26 20:37 GMT+02:00 Mark Côté <mc...@mozilla.com>:
>
>> 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
>>

>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>

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


--

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]

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]

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.

[Karl Tomlinson]

Interesting. n and p will include "Done" inline comments but the
x / y comments button skips "Done" inlines.

But please don't depend on either of these to find all issues that
need to be addressed. Neither will include inline comments made
on previous diffs that have not been ported to ghost comments on
the latest diff.

I wonder what the "x" is in x / y. (I was guessing it would show
the current inline number but it doesn't.)

[Dão Gottwald]

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

[smaug]

On 09/05/2018 06:40 AM, Kris Maglione wrote:
> 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.
>

Yeah, this new work mode is really not working well enough, at least from reviewer's point of view.


-Olli

[Eric Shepherd (Sheppy)]

Yes, we have found that and have been using it but as you say, it loses
some of the detail that has been historically helpful when writing
documentation. We eagerly await the redirect tool.

I do have concerns, reading the comments about Phabricator and usability,
but I will wait to comment myself until I've had a chance to really make
use of it, other than to say that the MDN web docs team spends a lot of
time reading through the comments and review notes on bugs, for obvious
reasons. Anything that makes that take longer or involve more clicks and
less convenience makes me really nervous about productivity impact.

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

[glob]

the redirect tool went live at the end of last week.

Eric Shepherd (Sheppy) wrote on 10/9/18 7:44 pm:

> Yes, we have found that and have been using it but as you say, it loses
> some of the detail that has been historically helpful when writing
> documentation. We eagerly await the redirect tool.