1929372 - [mozversioncontrol] Add unofficial support for Jujutsu repositories

Status: RESOLVED FIXED

(Firefox Build System :: General, task, P3)

Description

[Andrew Halberstadt [:ahal]]

Many of us have started using Jujutsu for development in mozilla-central. While Jujutsu itself works really well (on top of git-cinnabar), some of our tooling can cause a few rough edges. Most (if not all) of these rough edges could be smoothed with a specialized JujutsuRepository class in mozversioncontrol.

This bug aims to add unofficial support for Jujutsu. This does not mean Jujutsu will become an officially supported way of working with Firefox. Any fixes / improvements here will need to be developers scratching their own itch.

I'm open to ideas on how best to communicate this. I'm thinking a warning that gets printed the first time the JujutsuRepository class is initiated that needs to be acknowledged.

Comment 1

[Andrew Halberstadt [:ahal]]

Attachment: Bug 1929372 - [mozversioncontrol] Refactor into vcs specific submodules, r?sheehan

I don't love monolithic files, this simply moves things around to
submodules without changing any logic.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3e7991b6ea82
[mozversioncontrol] Refactor into vcs specific submodules, r=sheehan

Comment 3

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/3e7991b6ea82

Comment 4

[Mike Hommey [:glandium]]

Moving mozversioncontrol around broke at least this:
https://searchfox.org/mozilla-central/rev/f2df1ff64cb876e10c72ce7eed1fc9eac3f877bb/python/mozbuild/mozbuild/artifact_commands.py#449

Comment 5

[Andrew Halberstadt [:ahal]]

Attachment: Bug 1929372 - [mozversioncontrol] Fix missing import shim to SrcRepository, r?sheehan

Comment 6

[Andrew Halberstadt [:ahal]]

Sorry, I missed that shim, patch is up.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1631a4d2ffc4
[mozversioncontrol] Fix missing import shim to SrcRepository, r=sheehan

Comment 8

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/1631a4d2ffc4

Comment 9

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1929372 - Implement JujutsuRepository in mozversioncontrol.repo.jj to allow using JJ directly (on top of a git repository, whether colocated or not). Warns unless $MOZ_AVOID_JJ_VCS for now, to avoid incurring a maintenance burden. r=ahal

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d33734cbe630
Implement JujutsuRepository in mozversioncontrol.repo.jj to allow using JJ directly (on top of a git repository, whether colocated or not). Warns unless $MOZ_AVOID_JJ_VCS for now, to avoid incurring a maintenance burden. r=ahal

Comment 11

[agoloman]

Backed out for causing python failures.

• Backout link
• Push with failures
• Failure Log

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/39d2faeed169
Implement JujutsuRepository in mozversioncontrol.repo.jj to allow using JJ directly (on top of a git repository, whether colocated or not). Warns unless $MOZ_AVOID_JJ_VCS for now, to avoid incurring a maintenance burden. r=ahal

Comment 13

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/39d2faeed169

Comment 14

[Steve Fink [:sfink] [:s:]]

Taking the bug so regressions get blamed on the right person.

Comment 15

[:Gijs (he/him)]

All the regressions are closed, and searching bmo for jujutsu or jj only finds moz-phab bugs and bug 1964759 (which is a generic issue with pipelint). Can we omit the MOZ_AVOID_JJ_VCS warning by default now, do we think? If not, what would it take for that to happen?

Comment 16

[Steve Fink [:sfink] [:s:]]

The purpose of the warning was to avoid dumping bugs on the DevEx team (not sure what the official abbreviation is) with the expectation that they "should" be fixed because of it being a supported configuration. That concern was highest when (1) the support was new and untried, and (2) we were in the midst of the hg->git migration. It is still an officially unsupported configuration, though, so it's still a valid concern.

With that in mind I don't feel like I should have any say in whether the warning is removed or not, it's really for that team to decide since they'll be the ones getting support requests. (To be clear, I intend to keep fixing things that come up when I can.)

Accordingly, I'll 301 to ahochheiden.

Comment 17

[Alex Hochheiden [:ahochheiden] [he/him]]

(In reply to Steve Fink [:sfink] [:s:] from comment #16)

The purpose of the warning was to avoid dumping bugs on the DevEx team (not sure what the official abbreviation is)

Engineering Workflow. 🙂

(In reply to :Gijs (he/him) from comment #15)

Can we omit the MOZ_AVOID_JJ_VCS warning by default now, do we think? If not, what would it take for that to happen?

I think we're close, but we're still waiting on bug 1964150 for official moz-phab support. I spoke to Glob about this a while back and plan on making this an officially supported workflow, but that was a hard blocker from his perspective before we can make that distinction.

I plan to update the 'getting started' docs to reflect that once we have the official moz-phab support (Similar to how when hg was recommended there were hints that git was also supported, essentially providing bread crumbs to the jujutsu doc). I've already updated ./mach vcs-setup to support jj, and made the mozversioncontrol tests run with jj in CI. I think jj fix was broken again at some point, but maybe only on Windows (It hasn't worked for me for a while but I haven't gotten around to investigating yet).

There was also an idea floated to bootstrap jj as a toolchain (to ensure everyone is on the same version), but that's not necessarily a blocker.

I'm not sure what specifically we're waiting on in bug 1964150, I think it was regarding tests? Some sections of moz-phab that do not have test coverage were modified, so the ask was to implement tests for that section and I think that's what we're waiting on? So theoretically somebody could jump in to help push that along.

And to be clear, I'm definitely not the sole gatekeeper here, I've just kind of volunteered to give this the attention I feel it deserves.

Comment 18

[Erich Gubler [:ErichDonGubler] (he/him)]

As the person authoring patches for bug 1964150: the first step is to get patches for bug 1956345 landed, though I'm not sure what we're waiting on there either. I'll ping Connor Sheehan to see if there's anything on his end he'd like to see first; it's been a few weeks since I've followed up, and I haven't made any changes during that time.

ETA: https://bugzilla.mozilla.org/show_bug.cgi?id=1956345#c7

Comment 19

[Steve Fink [:sfink] [:s:]]

(In reply to Alex Hochheiden [:ahochheiden] from comment #17)

(In reply to Steve Fink [:sfink] [:s:] from comment #16)

The purpose of the warning was to avoid dumping bugs on the DevEx team (not sure what the official abbreviation is)

Engineering Workflow. 🙂

Ah right, sorry, I should know that from the newsletter.

As for an abbreviation, I propose "EWw". 😜