←back to thread

848 points thefilmore | 2 comments | | HN request time: 0s | 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 #
lupusreal ◴[] No.43971472[source]
> 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..)

replies(5): >>43971541 #>>43971614 #>>43971672 #>>43972086 #>>43973634 #
1. dblohm7 ◴[] No.43973634[source]
I understand what you're saying, but still:

GitHub issues is terrible compared to Mozilla's Bugzilla instance. It's not even close.

replies(1): >>43974805 #
2. nirvdrum ◴[] No.43974805[source]
I wish GitHub had a way to interface with an external issue tracker. I know it's not entirely on them, but it'd be great if there were some sort of standard for this. I'd love to embed an issue tracker from elsewhere.