Re: Upcoming changes to hg.mozilla.org access
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
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 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 > 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 > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
On Mon, Nov 4, 2019 at 8:36 AM David Teller 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 On 03/11/2019 11:14, Emilio Cobos Álvarez wrote: > > 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 > > > > > >> ___ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > >> > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
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 On 03/11/2019 11:14, Emilio Cobos Álvarez wrote: > 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 > > >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
On 11/1/19 4:03 PM, Andrew Sutherland wrote: 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. 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.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
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 On Fri, Nov 1, 2019 at 4:56 PM Andrew Halberstadt wrote: > 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 > > > On Fri, Nov 1, 2019 at 4:39 PM Kim Moir 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 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 >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
