Mozilla Firefox – Official GitHub repo

Thanks to the decentralised nature of git, this should matter only moderately.

Both forks coexist and pull fixes from each other.

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...

I 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) 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.

If you provide an http based front end to git, one of the significant (newish) challenges of self hosting is dealing with AI bots/scrapers.

I was gonna say they already were and had been for a while, but apparently a few weeks ago they moved back in to the main Firefox repo.

Which means I guess they're back on Github now.

Gecko and Firefox have been using Bugzilla for more than 25 years at this point. There's a lot of internal workflows, tooling and processes that are really dependent on the specific functionality in Bugzilla. I think it would be an extremely high risk project to try and replace Bugzilla with GitHub issues.

That said, there are also other teams and projects who do use GitHub for issue tracking. However the closer to Firefox/Gecko you are the harder this gets. For example it's hard to cross-reference GitHub issues with Bugzilla issues, or vice versa. I've seen people try to build two-way sync between GitHub and Bugzilla, but there are quite considerable technical challenges in trying to make that kind of cross-system replication work well.

However your point that GitHub makes issue submission easier for people who aren't deeply embedded in the project is a good one. I'm directly involved with webcompat.com, which aims to collect reports of broken sites from end users. It's using a GitHub issue tracker as the backend; allowing developers to directly report through GitHub, and a web-form frontend so that people without even a GitHub account can still submit reports (as you can imagine quite some effort is required here to ensure that it's not overwhelmed by spam). So finding ways to enable users to report issues is something we care about.

However, even in the webcompat.com case where collecting issues from people outside the project is the most important concern, we've taken to moving confirmed reports into bugzilla, so that they can be cross-referenced with the corresponding platform bugs, more easily used as inputs to prioritization, etc. That single source of truth for all bugs turns out to be very useful for process reasons as well as technical ones.

So — (again) without being any kind of decision maker here — I think it's very unlikely that Firefox will move entirely to GitHub issues in the foreseeable future; it's just too challenging given the history and requirements. Having some kind of one-way sync from GitHub to Bugzilla seems like a more tractable approach from an engineering point of view, but even there it's likely that there are non-trivial costs and tradeoffs involved.

Moving 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? :-)

I understand what you're saying, but still:

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

I suspect that Firefox is not bottlenecked on number of bug reports they got.

If you really want bug reports just make it a single form without the need to create an account. Github, Gitlab, etc., is a wall for 99% of web browser users.

I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process.

Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.

I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches.

So yeah, there's that.

It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.

(aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)

You just showed the poster-child of gatekeeping that is harming Open Source.

Every contributor is valuable, it's in the name, the definition of "contribute".

Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse.

Now, to be clear, while I do think GitHub is currently the "solution" to lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?

I can say that I've chosen not to bother when submitting a fix requires me to stray away from GitHub, and doubly so when it doesn't use a PR/MR workflow. There are only so many hours in the day, and I don't have the patience to deal with unconventional workflows when there are other things I could be doing with my time.

For projects that I'd be interested in being a long-term contributor to, this is obviously different, but you don't become a long-term contributor without first dealing with the short-term, and if you make that experience a pain, I'm unlikely to stick around.

A big part of this is the friction in signing up; I hope federated forges become more of a thing, and I can carry my identity around and start using alternate forges without having to store yet another password in my password manager.

Contribution isn’t driven by a desire for rewards, but by goodwill. Friction only gets in the way. If the friction is worth it, fine - but what exactly is being lost by moving the repository to GitHub?

How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?

The barriers may keep out low effort submissions*, but they also keep out contributors whose time is too valuable to waste on installing and configuring a bespoke setup based on some possibly outdated wiki.

* contributors need to start somewhere, so even broken PRs can lead to having a valuable contributor if you're able to guide them.

So, you're saying that because they don't know to use A they are likely to also don't know enough to contribute to B?

Being a good coder has absolutely no correlation to being good at using Mercurial.

Hang on. If they are deterred, then by definition they are not valuable contributors. They have not contributed. If they have contributed, they were not deterred.

Searchfox didn't exist back then, "there [was] only xul", I mean MXR of course.

Then MXR got replaced by DXR, itself replaced in 2020 by Searchfox (introduced in 2016).

https://discourse.mozilla.org/t/decommission-dxr/69475

https://billmccloskey.wordpress.com/2016/06/07/searchfox/

It’s interesting how pull requests remain the only tab (apart from code) that cannot be disabled by the repo owners.

I get it from GitHub’s perspective, it’s a nudge to get people to accept the core premise of ”social coding” and encouraging user pressure for mirrored projects to accept GitHub as a contribution entrypoint. I’m impressed by their successes and would attribute some of that to forced socialization practices such as not allowing PRs to be disabled. I’ve grown to dislike it and become disillusioned by GitHub over the course of a long time, but I’m in awe of how well it has worked for them.

My point doesn't really dispute that hg is dead "for most people" whatever that means, it's just that what the hg people could point to in the past was firefox, but now they've lost that example. Now, we can surely say it is dead.

To be frank, I know of no other major project that used hg. In fact, I think firefox was how I learned about it in the first place many years ago.

My honest opinion is that I hate that git won, it's too complicated for no benefit with complexity I personally will never leverage as a scientist who doesn't work in large teams.

I use it for visibility and ease, that's all. Otherwise I personally dislike it.

I'm a pretty young developer and git is the only VCS I'm familiar with, and even though it has its quirks I find it quite powerful and a perfectly adequate tool for the job. In what way is Mercurial better?

The GitHub SSO is annoying. I can't even view public issues if I'm logged in to GitHub, but haven't recently re-authenticated with SSO.

GitHub also has a lot of features and authentication scopes tied to the whole org, which is pretty risky for an org as large as Mozilla.

There is an “Enterprise” level above the org, but that obviously needs an Enterprise account. It lets you manage some policies across multiple orgs, including membership.

I am a Firefox developer, and you're spot on. Previously there were separate hg repos for central, beta, release. I think ESRs too. And autoland. Now they're all branches in the same repo, and central is renamed main.

Commits land in autoland and get backed out if they cause test failures. That's merged to main ~twice per day when CI is happy

Interesting that their issues are blamed on "dual SCM", not on Mercurial itself. I guess just the weight of contributors expecting Git as the default is sinking the big Mercurial projects these days.

Not yet at least. Currently both are still supported, it's just that the core repo is now in git syncing to hg rather than the other way around.

But I think hg support is going away. We hg enthusiasts at Mozilla are mostly fleeing to Jujutsu.