At this time, the cedar branch should be passing all tests - https://treeherder.mozilla.org/#/jobs?repo=cedar - and can be merged back to mozilla-central.

You can also choose merge it to autoland/ inbound first if that better suits our current workflow.

I've done a merge from m-c this morning (CET), but it might need another. If there's any issue, please contact me and I'll fix anything that needs manual intervention.

I've just pushed another merge to cedar.

Connor, is someone on your team able to pick this up relatively soon?

Hey Mike,

I'm not sure that merging commits from project repos is the correct way to land these changes on central. My suggestion would be to go through the standard Phabricator/Lando workflow, using rMOZILLACENTRAL as the review repository.

I asked around to a few people and there doesn't seem to be a standard way to land things from project repos.

:rail, :catlee, how does your team land changes from jamun, maple, etc on to central?

(In reply to Connor Sheehan [:sheehan] from comment #3)

Hey Mike,

I'm not sure that merging commits from project repos is the correct way to land these changes on central. My suggestion would be to go through the standard Phabricator/Lando workflow, using rMOZILLACENTRAL as the review repository.

Using Phabricator/ Lando is not possible, because these patches bitrotted considerably and would cause me to spend two days on fixing things up.

I asked around to a few people and there doesn't seem to be a standard way to land things from project repos.

Indeed, I'm betting that's it's a manual process, albeit a very easy one. Project repos exist for this sole purpose... It's just that it's used & done very sparingly.
Please merge cedar into m-c. If it happens to break anything - which I highly doubt, because all the tests pass on cedar with the latest patches of m-c merged in - just back it out again. Backing it out will also be super simple, because it's a single commit and the process can be tracked in this bug.

With 'single commit' I meant that it's a single merge commit, as parent for the commits that differ from m-c.

We use jamun and maple to test individual changes and never merge back to central. It's more like a try for release automation.

(In reply to Mike de Boer [:mikedeboer] from comment #4)

(In reply to Connor Sheehan [:sheehan] from comment #3)

Hey Mike,

I'm not sure that merging commits from project repos is the correct way to land these changes on central. My suggestion would be to go through the standard Phabricator/Lando workflow, using rMOZILLACENTRAL as the review repository.

Using Phabricator/ Lando is not possible, because these patches bitrotted considerably and would cause me to spend two days on fixing things up.

I asked around to a few people and there doesn't seem to be a standard way to land things from project repos.

Indeed, I'm betting that's it's a manual process, albeit a very easy one. Project repos exist for this sole purpose... It's just that it's used & done very sparingly.
Please merge cedar into m-c. If it happens to break anything - which I highly doubt, because all the tests pass on cedar with the latest patches of m-c merged in - just back it out again. Backing it out will also be super simple, because it's a single commit and the process can be tracked in this bug.

Ok here is my two cents, as a long time contributor and employee....

The general policy is that no code that ever lands on a l2 repo, when it is l2, should be merged into m-c without an explicit review.

We want unique commits that sheriffs can backout should they need to, that properly identify what changed. This facilitates better BLAME for the source code, as well as introspection as to what changed in a given time frame and the overall current state, and relevant bugs with any new code.

Hg does not allow hg backout on a merge commit, which would make sheriffs life much more difficult with any merge issues after this lands. Additionally hg allows merges to have additional changes (e.g. to solve a merge conflict) that could introduce security or other bugs, so they are not free.

Relevant Docs I was able to find:
https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities
https://wiki.mozilla.org/Commit_Policy:Current_Procedures

To actually land your code, I suggest the following:

Create a single (or multiple) diffs against central: hg diff -r "ancestor(central,maple):maple" this will give you a diff from the last merge head of central to the tip of maple (all changes that are on maple)... export that diff as a patch file (... > /tmp/maple.patch.diff) and then import that on central's head, hg up -r central; hg import /tmp/maple.patch.diff --no-commit.

Finally create a commit based on that patch, that you then submit to phabricator and get a relevant r+ for, and then land through autoland. This won't take a lot of time on your end (it can take longer if you are splitting out multiple unique pieces of code into a micro-commit, which is much better, but not required)
hg commit then use your phabricator command. (moz-phab, arc diff, whatever)

To do as you asked, I think at the bare minimum you'd need sheriff and relman buy in to have this code merged directly from this L2 project branch.

(In reply to Justin Wood (:Callek) from comment #7)

To do as you asked, I think at the bare minimum you'd need sheriff and relman buy in to have this code merged directly from this L2 project branch.

If you do get RelMan on board with merging into central, please have them or the code sheriffs perform the merge for you.

We kept this an L2 branch, even though I tried changing this in the config, because that was causing failures in other areas.

But it's good to know; I'll never use a project branch again.

Justin, thanks for your pointer - I was already wondering what the command to get the full diff might look like! I'll use this in bug 1524593.