Upcoming changes to hg.mozilla.org access

[Kim Moir]

The Engineering Workflow team enabled a hook in July which asked people to
provide a reason for directly pushing to hg.mozilla.org. Since it was
enabled, we have seen the number of direct pushes decrease to a few per
week.

Enabling developers to use standard tools to land reviewed code through a
secure pipeline also allows us to enable new workflow capabilities such as
running static analyzers, linters, and code formatting tools, while making
hg.mozilla.org more secure by reducing the number of people who can access
it directly. It also paves the way for decommissioning mozilla-inbound,
which will simplify our tree management and reduce infrastructure costs.

On Nov 14, 2019, we intend to change the permissions associated with Level
3 access to revoke direct push access to hg.mozilla.org on mozilla-inbound,
mozilla-central, mozilla-beta, mozilla-release and esr repos. If you do
need a patch landed outside the Phabricator/Lando pipeline such as in the
case of bustage, please use the #checkin-needed process
https://wiki.mozilla.org/Sheriffing/How_To/Landing_checkin-needed_patches
and contact the sheriffs in #sheriffs in Slack or IRC to land your patch.

Specific teams will retain direct access to hg.mozilla.org (now called
Level 4) such as Sheriffs and Release Management. We expect everyone else
to use the Phabricator/Lando pipeline, but exceptions may be granted for
special situations with director-level approval. If this applies to you,
please follow up with your manager.

The Engineering Workflow team is committed to supporting and improving the
productivity of developers working on Firefox. If you have questions or
need help with tooling, please reach out to us in the #phabricator Slack
channel.

Kim

[Mike Conley]

\o/

I think this is a really good thing. The smaller the surface for people to
land code without sufficient guarantees that it went through a review
mechanism, the better.

Thanks to you and your team for their work!

-Mike

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

[Andrew Halberstadt]

Very nice!

Does this mean mozilla-inbound is effectively decommissioned at this point?
Are there any circumstances it will need to run things in CI beyond
November 14th?

-Andrew

[Kim Moir]

Officially decommissioning m-i will take place after we change the
permissions. It will remain a read-only repo for historical purposes. No I
don't see a need to run things in CI on m-i beyond that date.
deprecate mozilla-inbound after Lando is used for most mozilla-central
landing
https://bugzilla.mozilla.org/show_bug.cgi?id=1530401

Kim

[Andrew Sutherland]

On 11/1/19 4:39 PM, Kim Moir wrote:
> On Nov 14, 2019, we intend to change the permissions associated with Level
> 3 access to revoke direct push access to hg.mozilla.org on mozilla-inbound,
> mozilla-central, mozilla-beta, mozilla-release and esr repos.

For mozilla-beta, mozilla-release, and esr... does lando know how to
land to these, or is it the case that landings on these branches are
done based on the approval flags by people other than the patch author?

I ask because if I create a branch based on the hg unified repo
"release" tag and then use `moz-phab` to create a review, I assume what
happens if I try and land with "lando" is that it will try and land the
commit against mozilla-central and it may succeed if the file hasn't
changed too much in central versus where it was on the release branch.

Andrew

[Steve Fink]

I recently encountered this situation too. Perhaps I just haven't read
the right document, but what is the current procedure for manual backports?

I'm now accustomed to the Magic Backporting van der Fairy doing most of
my backports for me based on the approval flags. But if a patch doesn't
apply cleanly then I manually rebase onto the beta and/or esr branch. If
I can't push those myself, should I manually clear out the Phabricator
revision ID in the commit message so I can use moz-phab or phabsend to
create a new phabricator revision? I know those have a repo callsign of
MOZILLACENTRAL -- does that cover beta and esr too, or is there a
different callsign to use?

Or should I dig out bzexport and attach the patch to the bug? (That's
what I did, but I felt like I was leaning on van der Fairy's good graces.)

[Andreas Tolfsen]

Also sprach Kim Moir:

> On Nov 14, 2019, we intend to change the permissions associated
> with Level 3 access to revoke direct push access to hg.mozilla.org
> on mozilla-inbound,

Several modules have a policy that changes to documentation, e.g.
for https://firefox-source-docs.mozilla.org/, can be landed with
a=doc if you’re a peer. There has been discussion on this list
several times in the last few years about expanding this policy to
apply to the whole project.

The background is that as MDN is moving away from serving
Mozilla-specific developer documentation to be centred around the
web platform, there is a rising need to make it easy to keep developer
docs in-tree up to date.

Documentation changes have historically been well served by a “wiki
editing”/micro adjustments approach. I wonder if there is anything
we can do with Phabricator to ease review requirements for documentation
changes from peers?

Lastly, I sympathise with wanting to reduce the number of routes a
patch can take to reach central. This will in the long term make
it easier to write automated tooling for SCM (such as wptsync) and
audit changes.

[Emilio Cobos Álvarez]

On 11/2/19 12:53 PM, Andreas Tolfsen wrote:
> Documentation changes have historically been well served by a “wiki
> editing”/micro adjustments approach. I wonder if there is anything
> we can do with Phabricator to ease review requirements for documentation
> changes from peers?

I think you can land patches without review even with Lando. I
personally think that's acceptable for typo fixes / documentation
updates / etc.

It's certainly a few more clicks than `git push` / `hg push` though.

-- Emilio

[David Teller]

For what it's worth, when I last tried, I couldn't even `moz-phab
submit` a self-reviewed patch. I had to arbitrarily pick another
reviewer for a patch that was not meant for landing (it was a
demonstration of a reproducible bug in phabricator, but that's another
story).

Cheers,
Yoric

[Jan de Mooij]

On Mon, Nov 4, 2019 at 8:36 AM David Teller <dte...@mozilla.com> wrote:

> For what it's worth, when I last tried, I couldn't even `moz-phab
> submit` a self-reviewed patch. I had to arbitrarily pick another
> reviewer for a patch that was not meant for landing (it was a
> demonstration of a reproducible bug in phabricator, but that's another
> story).
>

Yes, moz-phab used to require a reviewer, but that was changed a year ago.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1482216

Jan

[Bastien Abadie]

On Saturday, November 2, 2019 at 12:03:25 AM UTC+1, somb...@gmail.com wrote:
> For mozilla-beta, mozilla-release, and esr... does lando know how to
> land to these, or is it the case that landings on these branches are
> done based on the approval flags by people other than the patch author?

I'm working on bringing the uplift request workflow to Phabricator and Lando.
When that work is done, you will be able to make an uplift request for any mozilla-central patch towards mozilla-beta, mozilla-release, and esr from Lando.

> I ask because if I create a branch based on the hg unified repo
> "release" tag and then use `moz-phab` to create a review, I assume what
> happens if I try and land with "lando" is that it will try and land the
> commit against mozilla-central and it may succeed if the file hasn't
> changed too much in central versus where it was on the release branch.

The workflow will also support diffs directly created on a repository that needs approval from Release Management: you will be able to use Lando to fill the uplift form and directly update your existing revision.

This work is still in early stages, and we are planning to iterate with Release Management and a few developers on the best workflow. I'll send an update to dev-platform once it's available.

Bastien

[Kim Moir]

Just a note to let everyone know the hg.mozilla.org permissions change was
implemented this morning. Thanks to everyone for the work that allowed us
to make our code repositories more secure.

Kim

On Fri, Nov 1, 2019 at 4:39 PM Kim Moir <km...@mozilla.com> wrote:

> The Engineering Workflow team enabled a hook in July which asked people to
> provide a reason for directly pushing to hg.mozilla.org. Since it was
> enabled, we have seen the number of direct pushes decrease to a few per
> week.
>
> Enabling developers to use standard tools to land reviewed code through a
> secure pipeline also allows us to enable new workflow capabilities such as
> running static analyzers, linters, and code formatting tools, while making
> hg.mozilla.org more secure by reducing the number of people who can
> access it directly. It also paves the way for decommissioning
> mozilla-inbound, which will simplify our tree management and reduce
> infrastructure costs.
>

> On Nov 14, 2019, we intend to change the permissions associated with Level
> 3 access to revoke direct push access to hg.mozilla.org on

> mozilla-inbound, mozilla-central, mozilla-beta, mozilla-release and esr

[Andreas Tolfsen]

Also search Emilio Cobos Álvarez:

> On 11/2/19 12:53 PM, Andreas Tolfsen wrote:
>> Documentation changes have historically been well served by a “wiki
>> editing”/micro adjustments approach. I wonder if there is anything
>> we can do with Phabricator to ease review requirements for documentation
>> changes from peers?
>
> I think you can land patches without review even with Lando. I
> personally think that's acceptable for typo fixes / documentation
> updates / etc.

I just tried this on a documentation change and found the process
a little confusing, so I will share my experience here.

Phabricator will not let you self-review a change, but Lando will
as Emilio says, allow anyone with Commit Access Level 3 to _land_
changes unreviewed.

You have to click the grayed-out “View stack in Lando” link in the
right hand side column and dismiss these warnings:

> • Has a review intended to block landing.
> • Is not Accepted.
> • No reviewer has accepted the current diff.


It would be nice if Phabricator would let L3 authors self-review
so that the commit message could be rewritten to indicate that the
change was r=me.

The inability to self-review in Phabricator also means it’s not
possible to remove blocking reviewers automatically added by Herald
rules.

I hope this helps everyone trying to land typo correction,
documentations updates, and similar fixups.