←back to thread

848 points thefilmore | 2 comments | | HN request time: 0.66s | source
Show context
jgraham ◴[] No.43970574[source]
(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

replies(5): >>43970669 #>>43971472 #>>43971745 #>>43974450 #>>43974555 #
iamcreasy ◴[] No.43970669[source]
Thanks for the added context.

If I may - what were the significant scale challenges for self hosted solution?

replies(3): >>43970862 #>>43970906 #>>43976364 #
jgraham ◴[] No.43970906[source]
Again, 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/late...

replies(2): >>43971007 #>>43977390 #
monegator ◴[] No.43971007[source]
why github and not codeberg? badwidth? $$$ from microsoft? (traffic, free training for copilot, ..)
replies(6): >>43971085 #>>43971120 #>>43971319 #>>43971424 #>>43972405 #>>43973600 #
Macha ◴[] No.43971085[source]
I'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
replies(3): >>43971343 #>>43973427 #>>43981144 #
Miaourt ◴[] No.43971343[source]
Maybe if Mozilla gave one hundredth of their CEO's salary in donation to Codeberg they would be more than happy and able to scale to nine nine :p
replies(1): >>43971396 #
1. prepend ◴[] No.43971396[source]
Maybe. Maybe not. If I was the person responsible for the code, I wouldn’t want to gamble on them becoming good enough for me to use.
replies(1): >>43971662 #
2. executesorder66 ◴[] No.43971662[source]
Yeah, it's not like they care about improving the state of the open source ecosystem anyway.