For a long time Firefox Desktop development has supported both Mercurial and Git users. This dual SCM requirement places a significant burden on teams which are already stretched thin in parts. We have made the decision to move Firefox development to Git.

  • We will continue to use Bugzilla, moz-phab, Phabricator, and Lando
  • Although we’ll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time
  • We’re still working through the planning stages, but we’re expecting at least six months before the migration begins

APPROACH

In order to deliver gains into the hands of our engineers as early as possible, the work will be split into two components: developer-facing first, followed by piecemeal migration of backend infrastructure.

Phase One - Developer Facing

We’ll switch the primary repository from Mercurial to Git, at the same time removing support for Mercurial on developers’ workstations. At this point you’ll need to use Git locally, and will continue to use moz-phab to submit patches for review.

All changes will land on the Git repository, which will be unidirectionally synchronised into our existing Mercurial infrastructure.

Phase Two - Infrastructure

Respective teams will work on migrating infrastructure that sits atop Mercurial to Git. This will happen in an incremental manner rather than all at once.

By the end of this phase we will have completely removed support of Mercurial from our infrastructure.

    • @Lord_ToRAEnglish
      20•10 months ago

      deleted by creator

      • @[email protected]
        7•1 year ago

        and really seems to like to make broad generalizations of his opinion like it’s fact.

        None of what Brodie said is baseless, even if some are more opinion than fact. He sight’s sources for a reason.

      • @jaybone
        5•1 year ago

        I’m just curious, why are PRs worse on GitHub compared to other git hosting services?

        • Rustmilian
          10•1 year ago

          Instead of using valid commit messages they just slap on “#42” which isn’t valid anywhere other than the GitHub web UI.

        • @[email protected]
          3•1 year ago

          Also, GitHub PRs atleast to me feel like they encourage reviewing changes by the total diff of the entire PR, and not each commit. I don’t want a slog of commits that don’t add any value - it just makes doing things like reverts more annoying. Stuff like Gerrit and phabricator enforce reviews by making you review individual commits / changes / whatever you want to call them and not branch diffs.

          • @[email protected]
            0•1 year ago

            GitHub has an option when merging a PR to “squash and merge”. This option squashes all of the commits on the PR branch into a single commit and cherry-picks it on top of the base branch. We use this by default in our open source projects at work. Most people are not gonna go through the effort of making a well defined patch series the way it would be required for a Linux kernel contribution. Most changes aren’t that big though and so it doesn’t really matter. Send as many commits as you want in the PR, I’ll just review the diff as a whole and squash it when I’m done. Workflows should adapt to user preference, not the other way, and this is a good example of that.

            • @[email protected]
              3•1 year ago

              How much of that is what GitHub encourages and how much of that is what Users prefer? Plenty of users seem to enjoy phabricator / Gerrit for code review in practice precisely because of their workflows.

              • @[email protected]
                1•1 year ago

                Well squash and merge isn’t default or pushed in any way. It’s an option, and we chose to enable it ourselves because that’s what works best for us. It’s what works well for many other projects too, which is why many choose to enable it instead of the default merge commit.

                • @[email protected]
                  1•1 year ago

                  Yeah, but phabricator and Gerrit are entirely separate workflows from GitHub, and a lot of people prefer that workflow because it leads to encouraging better histories and reviews. It helps you in getting rid of the “fixed typos” type of commits, while still letting you make larger PRs.

                  GitHub obviously does let you keep a clean git history, but the code review workflow in GH just doesn’t encourage reviewing commits.

                  • @[email protected]
                    1•1 year ago

                    I think the idea here is that reviewing individual commits is irrelevant if the plan is just to squash it all down. Each PR corresponds to a single change on the main branch in the end, the fact there was a main commit followed by a half size “fixed typos” and “fixed bug” commits doesn’t actually matter since it will be blown away in the end. The process results in the same clean history with good individual commits on the main branch, just as if the user squashes those commits locally before pushing it up to the code review platform.

    • @RegalPotooEnglish
      7•1 year ago

      … which is part of why they aren’t using GitHubs pull request feature to land changes?

      • Rustmilian
        1•1 year ago

        “at this time”

        Meaning they’re planning/considering to in the future.

            • Kogasa
              3•1 year ago

              I’m only a native English speaker, so guess I could be interpreting it wrong.

              You should try being a native English reader.

              What it means is “they will not be accepting pull requests at this time.” Whether or not they are open to changing this in the future is not specified. They have not specifically stated that this is off the table, nor have they stated this is their intent.

                • Kogasa
                  2•1 year ago

                  No. They’re just not publicly saying it’s off the table. Whether they’re entertaining it internally is a totally different question.

        • @RegalPotooEnglish
          -6•1 year ago

          And I’m sure you’ve got a long history of submitting patches to Firefox given your strong opinions on the process Mozilla uses to manage this?

          • Rustmilian
            5•1 year ago

            Nobody here needs “a long history of submitting patches to Firefox” to have an opinion on the tools used to manage the project. I assume that most here sharing their opinion don’t and yet you need not scroll far. You merely need some knowledge and experience with the tools, be it in personal, corporate, FOSS, etc. projects. Besides I don’t spend my free time helping FOSS projects just to use it to be like “my opinion better” that’s literally just the “appeal to authority fallacy”. But if you must know, I have helped here and there throughout the years under various different aliases/accounts. (Why “various aliases”? because I enjoy helping not some meaningless credit, it’s just how I am.)

            • @RegalPotooEnglish
              -4•1 year ago

              So what you are saying is that as someone who has never worked on the Firefox codebase, you still somehow know more about managing contributions to one of the largest FOSS projects in the world that has been running pretty successfully for the last 25 years?

              Idk, maybe try a bit of humility - like if it looks like they are making a weird decision, maybe it’s not because they are dumb and you are very smart, maybe it’s because they know stuff that you don’t?

              • Rustmilian
                5•1 year ago

                First off, not what I said.
                Second off, I never called them dumb. I actually happen to have a good relationship with them, so I take offense to what you’re implying. I mearly stated that I don’t like GitHub and gave some legitimate reasons. Which btw : 1000000723 1000000724 1000000728 Maybe the one who should learn humility is you.