←back to thread

848 points thefilmore | 1 comments | | HN request time: 0.245s | 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 #
matkoniecz ◴[] No.43971614[source]
I suspect that Firefox is not bottlenecked on number of bug reports they got.
replies(1): >>43972908 #
lupusreal ◴[] No.43972908[source]
Many times I have encountered Firefox bugs that either haven't been reported, or which bugzilla's shit search makes too hard for me to find. Usually that's where I give up because it's a pain in the ass to enter reports in bugzilla, the whole process seems intended to scare off anybody not in the organization.
replies(1): >>43976313 #
1. matkoniecz ◴[] No.43976313[source]
there are definitely not yet reported bugs!

this does not mean that reporting more bugs would result in noticeable improvements, as likely there are already too many reported bugs to process them

at least that is my impression based on fate of my bug reports