8 ms·
(I work at Mozilla, but not on the VCS tooling, or this transition) To give a bit of additional context here, since the link doesn't have any: The Firefox cod
by jgraham 1y ago
(I work at Mozilla, but not on the VCS tooling, or this transition)
To give a bit of additional context here, since the link doesn't have any:
The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI.
In the short term the mercurial servers still exist, and are synced from GitHub. That allows automated systems to transfer to the git backend over time rather than all at once. Mercurial is also still being used for the "try" repository (where you push to run CI on WIP patches), although it's increasingly behind an abstraction layer; that will also migrate later.
For people familiar with the old repos, "mozilla-central" is mapped onto the more standard branch name "main", and "autoland" is a branch called "autoland".
It's also true that it's been possible to contribute to Firefox exclusively using git for a long time, although you had to install the "git cinnabar" extension. The choice between the learning hg and using git+extension was a it of an impediment for many new contributors, who most often knew git and not mercurial. Now that choice is no longer necessary. Glandium, who wrote git cinnabar, wrote extensively at the time this migration was first announced about the history of VCS at Mozilla, and gave a little more context on the reasons for the migration [1].
So in the short term the differences from the point of view of contributors are minimal: using stock git is now the default and expected workflow, but apart from that not much else has changed. There may or may not eventually be support for GitHub-based workflows (i.e. PRs) but that is explicitly not part of this change.
On the backend, once the migration is complete, Mozilla will spend less time hosting its own VCS infrastructure, which turns out to be a significant challenge at the scale, performance and availability needed for such a large project.
[1] https://glandium.org/blog/?p=4346 https://glandium.org/blog/?p=4346
- iamcreasy 1y agoThanks for the added context. If I may - what were the significant scale challenges for self hosted solution?
- bayindirh 1y agoI guess it's the CI/CD infrastructure. Pipeline and time requirement grows exponentially as the code supports more operating systems and configurations. I used a GitLab + GitLab Runner (docker) pipeline for my Ph.D. project which did some verification after every push (since the code was scientific), and even that took 10 minutes to complete even if it was pretty basic. Debian's some packages need more than three hours in their own CI/CD pipeline. Something like Mozilla Firefox, which is tested against regressions, performance, etc. (see https://www.arewefastyet.com https://www.arewefastyet.com) needs serious infrastructure and compute time to build in n different configurations (stable / testing / nightly + all the operating systems it supports) and then test at that scale. This needs essentially a server farm, to complete in reasonable time. An infrastructure of that size needs at least two competent people to keep it connected to all relevant cogs and running at full performance, too. So yes, it's a significant effort.
- notpushkin 1y agoI think the CI/CD infra stays intact here though? (and even then, I imagine GitHub Actions bill would be enormous for a project like Firefox)
- bayindirh 1y agoI think it can be done half/half. Do some, well-defined builds at GitHub and pull in for testing. Another comment tells that some users needed 10+ minutes to get a lock to pass their tests through CI, so maybe some sanity tests can be offloaded to GitHub actions. I'm not claiming that my comment was 100% accurate, but they plan to move some of the CI to GitHub, at least.
- TheDong 1y ago> but they plan to move some of the CI to GitHub, at least Really? I've seen no indication of that anywhere, and I'd be amazed if they did. They're not using github PRs, and github actions really fights against other development workflows... not to mention they already have invested a lot in TaskCluster, and specialized it to their needs. Where are you getting that from?
- jgraham 1y agoAgain, I can only comment from the perspective of a user; I haven't worked on the VCS infrastructure. The obvious generic challenges are availability and security: Firefox has contributors around the globe and if the VCS server goes down then it's hard to get work done (yes, you can work locally, but you can't land patches or ship fixes to users). Firefox is also a pretty high value target, and an attacker with access to the VCS server would be a problem. To be clear I'm not claiming that there were specific problems related to these things; just that they represent challenges that Mozilla has to deal with when self hosting. The other obvious problem at scale is performance. With a large repo both read and write performance are concerns. Cloning the repo is the first step that new contributors need to take, and if that's slow then it can be a dealbreaker for many people, especially on less reliable internet. Out hg backend was using replication to help with this [1], but you can see from the link how much complexity that adds. Firefox has enough contributors that write contention also becomes a problem; for example pushing to the "try" repo (to run local patches through CI) often ended up taking tens of minutes waiting for a lock. This was (recently) mostly hidden from end users by pushing patches through a custom "lando" system that asynchronously queues the actual VCS push rather than blocking the user locally, but that's more of a mitigation than a real solution (lando is still required with the GitHub backend because it becomes the places where custom VCS rules which previously lived directly in the hg server, but which don't map onto GitHub features, are enforced). [1] https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/replication.html#hgmo-replication https://mozilla-version-control-tools.readthedocs.io/en/late...
- monegator 1y agowhy github and not codeberg? badwidth? $$$ from microsoft? (traffic, free training for copilot, ..)
- Macha 1y agoI'm not sure codeberg has managed two 9s of uptime while I've been using it. Manageable when it's just a public mirror for occasional publishing of my small hobby projects, but I wouldn't recommend it for Firefox sized projects
- PaulDavisThe1st 1y agoIf you provide an http based front end to git, one of the significant (newish) challenges of self hosting is dealing with AI bots/scrapers.
- lupusreal 1y ago> This only affects the code; bugzilla is still being used for issue tracking Grim. The best reason to be using github at all is to maximize the portion of your users who are comfortable submitting bug reports, as they already have an account and are familiar with how the platform works (due to network effects.) Projects which host code on github but chose not to take bug reports there are effectively gate keeping bug submission, by asking their users to jump through the hoops of finding the site, signing up for it, and learning to use a new interface. I've done this before, with Bugzilla and Firefox, to submit a bug report for an accessibility bug on MacOS and it was a pain in the ass that I put off for a long time before becoming annoyed enough to go through the process. (End result: the bug was confirmed but never fixed..)
- dspillett 1y agoMoving the existing data over might not be a quick and easy task, so takes planning. Perhaps they intend to move over but didn't want to do everything in one go. Making many changes at the same time can be much more risky than a staged approach. > are effectively gate keeping bug submission Of course this could be a benefit… Have you seen the quality of bug reports coming from some people, even other devs? :-)
- lupusreal 1y agoI've been on the front line of user bug reports for much of my career, so I definitely know what it's like. I also have very little sympathy for the complaints. Devs want to only take bug reports from other devs, and more so, only experienced devs, and more so, only devs specifically with experience with that specific project... That's great for the short term interests of the devs but not for the long term prospects of the project. It's really not that hard to sort through user bug reports, find and categorize the ones that are actionable and respond with boilerplate requests for more information to the rest. It's not super enjoyable, it's work, but it's absolutely manageable and devs need to keep some perspective when they complain about it. I think maybe a mandatory part of every CS education should be an internship in messy and difficult manual labor so that devs have some real context about what it means for a job to be unpleasant.
- emigre 1y agoThanks for the context. IMHO I don't think Mozilla should have decided to move to a closed-source platform owned by Microsoft.
- fguerraz 1y agoThanks to the decentralised nature of git, this should matter only moderately.
- JeremyNT 1y agoExactly, now they have the best of both worlds: let Microsoft host the code using a standard VCS, but avoid lock in by continuing to use their own issue tracker and project management software.
- esseph 1y agoHAH!
- Cthulhu_ 1y agoOnly for as long as GH is only used for version control; if they also start to rely on PRs or issues or whatnot, the enmeshment will become worse.
- LtdJorge 1y agoWill GeckoView and Mozilla Android Components be on GitHub too?
- thayne 1y agoGiven that Phabricator has been discontinued, are there any plans to replace that with something else? Phorge perhaps?
- Operyl 1y agoBoth forks coexist and pull fixes from each other.