27 ms·

Mozilla Firefox – Official GitHub repo

855 points by thefilmore 1y ago

mlenz 1y ago
Great to see, but I wonder what lead to the decision of creating a new org instead of using github.com/mozilla
- temp0826 1y ago
  They have many orgs- https://wiki.mozilla.org/GitHub#other_github https://wiki.mozilla.org/GitHub#other_github
- moontear 1y ago
  Without knowing their reason, there are a few things tied to the org where multiple orgs make sense. If you do SSO for example you tie the org to a SSO provider, you can’t tie „just a few users“ to the SSO provider (afaik). The Firefox repo may have totally different authentication / users than the main Mozilla repo.
  - pornel 1y ago
    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.
- sofixa 1y ago
  GitHub are terrible at this, because you can't have levels other than Org and Repository. And many things (SSO, visibility rules, common configs) are on the org level. Unfortunately often the cleaner option is to create a separate org, which is a pain to use (e.g. you log in to each separately, even if they share the same SSO, PATs have to be authorised on each one separately, etc). In Gitlab, you would have had one instance or org for Mozilla, and a namespace for Firefox, another one for other stuff, etc.
  - captn3m0 1y ago
    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.
    - sofixa 1y ago
      But it still requires multiple orgs, and the UX is still poor. It's like AWS accounts vs GCP projects. Yeah, there are ways around the organisational limitations, but the UX is still leaky.
- baobun 1y ago
  Presumably a case of Conways. https://en.m.wikipedia.org/wiki/Conways_Law https://en.m.wikipedia.org/wiki/Conways_Law
CorrectHorseBat 1y ago
So they moved from hg to git? Or is this just an official mirror
- shit_game 1y ago
  firefox development has been moved from mercurial to git since early november of 2023 https://www.phoronix.com/news/Firefox-Going-Git https://www.phoronix.com/news/Firefox-Going-Git
  - swiftcoder 1y ago
    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.
    - dgoldstein0 1y ago
      Isn't mercurial abandonware? Or maybe I'm just remembering that gitlab dropped support. If it's not dead yet seems to be getting there
      - arp242 1y ago
        They had a release just a few days ago. It's definitely not abandonware.
      - swiftcoder 1y ago
        It’s still used by Meta, at any rate (albeit a very scaled version thereof). Meta picked it for their monorepo when Linus wasn’t willing to play ball on extending Git for their use case.
        arp242 1y ago
        Is it still used there? I know they did in the past, but reading up a bit on the background on all of this I found https://github.com/facebook/sapling https://github.com/facebook/sapling, and it seems that's what they're using now?
reddalo 1y ago
Why GitHub? If they truly cared about open-source they would've chosen something else, such as a self-hosted Forgejo [1], or its most common public instance Codeberg [2]. [1] https://forgejo.org/ https://forgejo.org/ [2] https://codeberg.org/ https://codeberg.org/
- AStonesThrow 1y ago
  > If they truly cared about open-source Perhaps Microsoft offered to pick up the tab that Google has been paying, but is now imperiled, or at least lend some sort of financial support, and Firefox cares more about paying their bills than open source
- mzi 1y ago
  Codeberg unfortunately have an abysmal uptime track record.
- danpalmer 1y ago
  I would argue that part of "truly caring" about open-source is being where the contributors and community are. That's probably a large part of the move to GitHub, and neither of these other options would achieve that. As much as one can say "git is distributed, the server doesn't matter", the centre of the community very much does matter, and for better or worse that's currently Github.
  - arccy 1y ago
    If you maintain a popular project, you'll quickly find that github prs are a massive source of spam and low quality prs with people that don't even bother to follow up. Bad PRs all around, with just a constant stream of drive by "why no merge?!?!?!" comments.
  - Tepix 1y ago
    We need to work on decentralisation of git forges, making it less relevant where a project is hosted by offering cross-instance collaboration and discoverability.
- gsich 1y ago
rrr_oh_man 1y ago
[flagged]
- dtech 1y ago
  If you had checked you would've seen issues are not enabled. I assume they still use their Bugzilla
  - gbil 1y ago
    and they moved anyway the android firefox issues from github to bugzilla some time ago, it would be quite "funny" moving them back to github now
  - rrr_oh_man 1y ago
    > If you had checked you would've seen issues are not enabled That was the point of the (obviously ill-received) joke.
    - calcifer 1y ago
      Ill-received or poorly stated? Try as I might, I can't find a joke in your comment.
      - nirava 1y ago
        I can. It was funny. No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once".
        arp242 1y ago
        > No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once". Never underestimate the cynicism of HN commenters.
bandrami 1y ago
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
- moralestapia 1y ago
  Care to explain?
  - aucisson_masque 1y ago
    Linus Torvalds invented git, which is what's used by GitHub and others like gitlab.
    - moralestapia 1y ago
      I know that, I just didn't get this part "and 20 years later we all use it to store our code in a single place". And as I can see here, no one else did ...
  - joha4270 1y ago
    If GitHub went down, how much would it impact the open source world? Sure, there would be local copies everywhere, but for a distribution version control system, it's pretty centralized at GitHub
    - kgeist 1y ago
      If GitHub went down, the code would be fine (just announce a new official URL), but the main thing that would be lost is issues and pull requests. Maybe Git should add official support for issues and pull requests in its metadata to be fully decentralized.
      - nurumaik 1y ago
        Fully decentralized metadata so we can finally have merge conflicts in PR comments while discussing merge conflicts
IshKebab 1y ago
Not for PRs or issues though which are arguably the biggest reasons to use GitHub. Still this is definitely an improvement.
- baq 1y ago
  Which is fascinating since both suck. Gerrit (replace with whatever if you please) is a much better change submission experience and basically anything else is a better bug tracker. The killer feature is collocation of features to a single forge, combined with a generous free tier it’s the windows xp of the ecosystem: everybody has it, everybody knows it, almost nobody knows anything else.
- matkv 1y ago
  So is this now just a mirror? I'm not sure what the point of moving to GitHub was then.
  - IshKebab 1y ago
    It's the primary repo rather than a mirror, but yeah I agree it they don't get most of the benefits. Moving issues and PRs is probably an enormous effort so I get why they aren't doing it all at once.
- elric 1y ago
  GitHub's issue tracker is easily the worst issue tracker I've ever used. It's at the same time incredibly limited in features, but somehow hard to navigate. As for PRs: I'm sure Mozilla welcome contributions, but accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage.
  - IshKebab 1y ago
    Count yourself lucky you haven't had to use Jira! Or bugzilla for that matter. I agree it is rather basic but I don't see how it's hard to navigate. > accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage. I don't think that really happens based on what I've seen of other huge projects on GitHub.
deleted 1y ago
[deleted]
thrdbndndn 1y ago
Correct me if I'm wrong, IIRC the previous "master" branch is `mozilla-central`. Now it has "main" and "autoland", what are they? Which one is the equivalent of mozilla-central before?
- chme 1y ago
  Not a firefox dev, but pretty sure its 'main' The "new" git default branch name is 'main' and 'autoland' existed before next to 'mozilla-central' and is the one where commits usually appear first.
  - jamienicol 1y ago
    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
    - thrdbndndn 1y ago
      Thanks for the clarification! I've mostly encountered these branches/repos when checking commits linked to Bugzilla tickets, and I don't recall seeing "autoland" show up too much in those cases.
mhh__ 1y ago
Inevitable. GitHub is a good platform in need of some proper dev workflows (pull requests are atrocious, branches footguns, yml driven CI is a noose) but they've obviously won.
- jopsen 1y ago
  I don't Firefox is moving to Github Actions anytime soon. I was pretty involved with the TaskCluster setup years ago, and it still seems to be running a bunch of CI things. mozilla-central has a LOT of tests -- each push burns a lot of compute hours.
  - sfink 1y ago
    Yes. All CI is remaining in TaskCluster. Bugs are remaining in bugzilla, not GH issues. Code review is remaining in Phabricator (pre-Phorge fork), pushing in Lando (a custom layer). Some associated projects are using more GitHub stuff.
DennisL123 1y ago
A BUILD.md could be useful.
- mdaniel 1y ago
  the readme is literally 21 lines long, and about 25% of them are blank lines, with the 2nd URL pointing to "how to contribute" and that link has a dedicated "how to build and run" https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html#to-build-run https://firefox-source-docs.mozilla.org/contributing/contrib... The bad news is that their build system is extremely hand-rolled, and so if it works for you, count yourself lucky, because when it doesn't work you're in for 4 hours of python hell
floriangosse 1y ago
I think it's actually an understandable strategical move from Mozilla. They might loose some income from Google and probably have to cut the staff. But to keep the development of Firefox running they want to involve more people from the community and GitHub is the tool that brings most visibility on the market right now and is known by many developers. So the hurdle getting involved is much lower. I think you can dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.
- fhd2 1y ago
  In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.
  - lpln3452 1y ago
    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?
    - Aachen 1y ago
      > what exactly is being lost by moving the repository to GitHub? Alternatives to github We lament Google's browser engine monopoly, but putting the vast majority of open source projects on github is just the expected course to take. I guess we'll repeat history once microsoft decides to set in the enshittification, maybe one day mobile OSes replace Windows and they're strapped for cash, who knows, but it's a centralised closed system owned by a corporation that absolutely adores FOSS I don't mind any particular project (such as this one) being in Github and I can understand that Mozilla chooses the easy path, they've got bigger problems after all, but it's not like there are no concerns with everyone and everything moving to github
mentalgear 1y ago
Would have been great if they used an European alternative ( like Codeberg ).
- selectnull 1y ago
  Mozilla is US organization, why would they care to?
  - neilv 1y ago
    As for European specifically, maybe the commenter was talking about data protection laws. If not, maybe (in many European countries at the moment) less national or business background of ruthlessness. I was thinking something different: I wonder whether Mozilla considered GitLab or Codeberg, which are the other two I know that are popular with open source projects that don't trust GitHub since it sold out to Microsoft. (FWIW, Microsoft has been relatively gentle or subtle with GitHub, for whatever reason. Though presumably MS will backstab eventually. And you can debate whether that's already started, such as with pushing "AI" that launders open source software copyrights, and offering to indemnify users for violations. But I'd guess that a project would be pragmatically fine at least near term going with GitHub, though they're not setting a great example.)
    - selectnull 1y ago
      Given the Mozilla direction lately, the last thing they want is good data protection laws.
      - fsflover 1y ago
        This is a huge exaggeration, borderline dishonest attack.
        selectnull 1y ago
        Time will tell. I would love to be wrong.
antalis 1y ago
Firefox Mobile (Fenix) had just moved to Mozilla's Mercurial mozilla-central repository after using GitHub including for issues. https://github.com/mozilla-mobile/firefox-android/wiki#upcoming-migration-to-mozilla-central https://github.com/mozilla-mobile/firefox-android/wiki#upcom... Now, both the desktop and the mobile version will be on Github, and the "issues" will stay on Bugzilla. This will take advantage of both GitHub's good search and source browsing and Git's familiar system. As a former Firefox and Thunderbird contributor, I have to say that I used local search instead of trying to find something on the mozilla-central website. Of course, when you're actively developing software, you search inside your IDE, but allowing to find things easily on the website makes it more welcoming for potential new contributors.
- adrian17 1y ago
  > I have to say that I used local search instead of trying to find something on the mozilla-central website. On the contrary, I find searchfox to be the best code navigation tool I used. It has nice cross-language navigation features (like jumping from .webidl interface definition to c++ implementation), it has always-on blame (with more features too) and despite that it's really fast and feels extremely lightweight compared to GitHub interface. I really wish I had this with more projects, and I'll be sad if it ever dies.
  - antalis 1y ago
    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://discourse.mozilla.org/t/decommission-dxr/69475 https://billmccloskey.wordpress.com/2016/06/07/searchfox/ https://billmccloskey.wordpress.com/2016/06/07/searchfox/
- baobun 1y ago
  > This will take advantage of both GitHub's good search and source browsing and Git's familiar system. The source browsing has detoriated severely relatively recently IME, to the point where i can't be called "good" anymore. It now loads asynchronously (requiring js) and lazily, randomly breaks on shaky connections and in-page search is broken. The recent issues/PRs revamp is also a pretty major step back. Try searching in PRs with all uBlock Origin lists enabled.
tgsovlerkhgsel 1y ago
On one hand, centralization at a commercial provider isn't great. On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.
- smallnix 1y ago
  I wish I could search on GitHub without logging in
  - nicce 1y ago
    They used to have 64 core 32 machine cluster just for search. You may want to reduce unnecessary search. https://github.blog/engineering/the-technology-behind-githubs-new-code-search/ https://github.blog/engineering/the-technology-behind-github...
    - mdaniel 1y ago
      This from a company that uses Ruby for their webapp and hosts probably one of the bigger CI build farms probably in the world. I have a very hard time crying because they have to run a beefy search cluster. I would guess that a very non-trivial portion of the horsepower for such a thing is about ingest of the constant updates moreso than the actual search part
  - hedayet 1y ago
    I wish that too, and I’ve always wanted to offer features like this in everything I build. But it’s a lot of work to prevent abuse, especially for resource intensive features when supporting unsigned-in use cases.
- elric 1y ago
  > Just finding the repo is often a frustrating exercise Surely most open source projects have a link to their source code? Whether it's github, gitlab, sourcehut, or anything else?
rvz 1y ago
Centralizing everything to GitHub really isn't a good idea given their frequent incidents every week.
petepete 1y ago
I wonder how long it'll take for my PR which entirely removes the built in Pocket integration will take to be dismissed.
- petepete 1y ago
  Thankfully it won't be necessary!
mritzmann 1y ago
What is the source of “Firefox Moves to GitHub”? It could be a mirror, just like Linux also has an mirror on GitHub. https://github.com/torvalds/linux https://github.com/torvalds/linux // EDIT: Source: https://news.ycombinator.com/item?id=43970574 https://news.ycombinator.com/item?id=43970574
- xrdev 1y ago
  My thoughts as well, even more so after seeing the only GitHub Workflow they have is actually for closing Pull Requests with a default response: https://github.com/mozilla-firefox/firefox/blob/main/.github/workflows/close-pr.yml https://github.com/mozilla-firefox/firefox/blob/main/.github...
  - sakjur 1y ago
    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.
octocop 1y ago
Nice, I was just checking yesterday to find the source code of firefox. Even if it is only a mirror it's a nice step to make it more available I think.
Kuinox 1y ago
It's good that they fixed one of the major tech debt for contributing to firefox. When I tried a few years ago, mercurial took multiple hours to clone, and I already had to use the unofficial git support in order to have things working before the end of the day. Their docs was also a mess back then and made me recompile everything even if it wasnt needed.
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 ago
  Thanks for the added context. If I may - what were the significant scale challenges for self hosted solution?
  - bayindirh 1y ago
    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 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.
kristel100 1y ago
Honestly surprised it took this long. For a project that depends so much on community contribution, being on GitHub just lowers the barrier for new devs. Curious to see if this revives contribution velocity.
- berkes 1y ago
  In the very least, it will open up FTEs that can now work on what makes Mozilla projects unique, rather than on building and maintaining generic fundamentals. It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.
roschdal 1y ago
Firefox moves to GitHub. Now someone better make a fork to make a proper web browser, small, fast, lean and without bloat and surveillance.
edelbitter 1y ago
So no IPv6 in the foreseeable future?
- baobun 1y ago
  It really is a bummer that we still can't clone over IPv6 in 2025. So annoying to have to set up (and pay for) IPv4 egress proxy on so many build systems and servers just because of this. https://github.com/orgs/community/discussions/10539 https://github.com/orgs/community/discussions/10539
bingemaker 1y ago
They already have an org github.com/mozilla. Why didn't they move ff source there?
nikolayasdf123 1y ago
nice, GitHub is defacto place to keep and release code
cubefox 1y ago
I assume this is now one of the largest (lines of code) projects on GitHub.
- mdaniel 1y ago
  I'd bet https://github.com/brave/brave-core https://github.com/brave/brave-core would top FF, since it's both chromium _and_ Brave's extra bits
mintplant 1y ago
Why is the mozilla-firefox org full of forks of the main repo named after trees? https://github.com/mozilla-firefox https://github.com/mozilla-firefox
- dblohm7 1y ago
  I haven't worked for Mozilla since 2021, but back then the branches named after trees were used as feature branches for large projects, at least until those projects were in a good enough state to cleanly merge back into trunk without breaking CI.
- kbrosnan 1y ago
  They are used for large scale landings or when a project needs to track trunk development but will churn a lot. https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectRepositories https://wiki.mozilla.org/ReleaseEngineering/DisposableProjec...
sylware 1y ago
Bad Move. github.com broke noscript/basic (x)html interop for most if not all core functions (which were working before). The issue system was broken not that long time ago. And one of the projects which should worry about, even enforce, such interop, moving to microsoft github... The internet world is a wild toxic beast.
zajio1am 1y ago
To me it seems absurd that such organization like Mozilla uses third-party hosting like GitHub instead of something self-hosted or at least running under their own name. I understand that one-person projects use GitHub, but forcing contributors to make account with third-party service seems contributor-hostile.
- garganzol 1y ago
  If it is an open source project then why not. This gives some visibility and welcoming openness to the project where everyone can contribute.
nolok 1y ago
I hope the bugzilla stay there even if only read only. There is a lot of historical data in there, especially for the web which was built as a "ad-hoc" platform, many times when you wonder why does X the answer can only be found in bugzilla (which will explain that some random website that used to be major but doesn't even exists anymore, did something for some browser that used to be major but doesn't even exists anymore).
- fergie 1y ago
  Bugzilla was really good, and in retrospect decades ahead of its time. There is probably no self hosted bug tracker that comes close (or it there?)
- sfink 1y ago
  Bugzilla is still the bug tracker for Firefox. I know if no plans to change that. (Github issues are not being used for the Firefox repo.)
upcoming-sesame 1y ago
Why did they choose the mozilla-firefox org as opposed to the already existing mozilla org ? https://github.com/mozilla https://github.com/mozilla
- alpha_trion 1y ago
  That's an excellent question
- heftig 1y ago
  Different access rules, I guess. Or maybe they wanted some separation from the existing org so the custom automation has no chance of doing collateral damage.
upcoming-sesame 1y ago
Why did they use mozilla-firefox org name instead of the already existing https://github.com/mozilla https://github.com/mozilla one ?
noobermin 1y ago
I guess the dream is dead. Even in open source, we have consolidation with no real hard monetary markets involved. EDIT: skimming these comments, I like how none of the top comments are talking about the bigger story here which is the move away from mercurial to git and instead everyone is focusing on github itself. This has essentially sealed hg away to obscurity forever. Do people not realise git is a program that runs on your computer and github is just a service that uses git? May be this is an old man gripe at this point but I'm surprised at the lack of technical discussion around this.
- dzaima 1y ago
  This is far from the first project to move from hg to git; many people probably just generally expect that to happen upon any source code management change for anything still using mercurial, which has already been effectively dead for most people for years.
  - noobermin 1y ago
    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.
- garganzol 1y ago
  I cannot imagine moving to Git from Mercurial. Git looks clunky from my perspective. Yes, it works too, but working with Git is a usability torture, sorry but it is true. I like some Git features better though, but not most of them.
  - static_motion 1y ago
    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?
elmer007 1y ago
Star Wars reference in a comment: https://github.com/mozilla-firefox/firefox/blob/917c73cfe1a5b7d78bf163edbd9b471563088192/modules/libmar/src/mar_create.c#L255 https://github.com/mozilla-firefox/firefox/blob/917c73cfe1a5... Fun to get a glimpse into someone's thought process while they were working.
thund 1y ago
Hate seeing how repos are so polluted by dot-files and dot-folders. I wish tools and SDKs converged into a single dot-folder, so that we could look at repos without seeing everything everywhere
metalliqaz 1y ago
What are 'pine', 'maple', 'holly', etc?
- hanlonsrazor 1y ago
  Internal nomenclature for feature branches.
InTheArena 1y ago
as a side note - I love the new bookmark tabs feature. About time :-)
frshOffTheBoat 1y ago
[dead]
deleted 1y ago
[deleted]
kidsil 1y ago
First commit: https://github.com/mozilla-firefox/firefox/commit/c4cc52826abd53e1121e4234d719cfd89ce58093 https://github.com/mozilla-firefox/firefox/commit/c4cc52826a... Hard to believe it's been 27 years. I remember when it was still in beta, and how exciting it was to have an open source alternative to Internet Explorer. Good times!

855 points by thefilmore 1y ago

mlenz 1y ago

Great to see, but I wonder what lead to the decision of creating a new org instead of using github.com/mozilla

temp0826 1y ago
They have many orgs- https://wiki.mozilla.org/GitHub#other_github https://wiki.mozilla.org/GitHub#other_github
moontear 1y ago
Without knowing their reason, there are a few things tied to the org where multiple orgs make sense. If you do SSO for example you tie the org to a SSO provider, you can’t tie „just a few users“ to the SSO provider (afaik). The Firefox repo may have totally different authentication / users than the main Mozilla repo.
- pornel 1y ago
  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.
sofixa 1y ago
GitHub are terrible at this, because you can't have levels other than Org and Repository. And many things (SSO, visibility rules, common configs) are on the org level. Unfortunately often the cleaner option is to create a separate org, which is a pain to use (e.g. you log in to each separately, even if they share the same SSO, PATs have to be authorised on each one separately, etc). In Gitlab, you would have had one instance or org for Mozilla, and a namespace for Firefox, another one for other stuff, etc.
- captn3m0 1y ago
  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.
  - sofixa 1y ago
    But it still requires multiple orgs, and the UX is still poor. It's like AWS accounts vs GCP projects. Yeah, there are ways around the organisational limitations, but the UX is still leaky.
baobun 1y ago
Presumably a case of Conways. https://en.m.wikipedia.org/wiki/Conways_Law https://en.m.wikipedia.org/wiki/Conways_Law

CorrectHorseBat 1y ago

So they moved from hg to git? Or is this just an official mirror

shit_game 1y ago
firefox development has been moved from mercurial to git since early november of 2023 https://www.phoronix.com/news/Firefox-Going-Git https://www.phoronix.com/news/Firefox-Going-Git
- swiftcoder 1y ago
  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.
  - dgoldstein0 1y ago
    Isn't mercurial abandonware? Or maybe I'm just remembering that gitlab dropped support. If it's not dead yet seems to be getting there
    - arp242 1y ago
      They had a release just a few days ago. It's definitely not abandonware.
    - swiftcoder 1y ago
      It’s still used by Meta, at any rate (albeit a very scaled version thereof). Meta picked it for their monorepo when Linus wasn’t willing to play ball on extending Git for their use case.
      - arp242 1y ago
        Is it still used there? I know they did in the past, but reading up a bit on the background on all of this I found https://github.com/facebook/sapling https://github.com/facebook/sapling, and it seems that's what they're using now?

reddalo 1y ago

Why GitHub? If they truly cared about open-source they would've chosen something else, such as a self-hosted Forgejo [1], or its most common public instance Codeberg [2]. [1] https://forgejo.org/ https://forgejo.org/ [2] https://codeberg.org/ https://codeberg.org/

AStonesThrow 1y ago
> If they truly cared about open-source Perhaps Microsoft offered to pick up the tab that Google has been paying, but is now imperiled, or at least lend some sort of financial support, and Firefox cares more about paying their bills than open source
mzi 1y ago
Codeberg unfortunately have an abysmal uptime track record.
danpalmer 1y ago
I would argue that part of "truly caring" about open-source is being where the contributors and community are. That's probably a large part of the move to GitHub, and neither of these other options would achieve that. As much as one can say "git is distributed, the server doesn't matter", the centre of the community very much does matter, and for better or worse that's currently Github.
- arccy 1y ago
  If you maintain a popular project, you'll quickly find that github prs are a massive source of spam and low quality prs with people that don't even bother to follow up. Bad PRs all around, with just a constant stream of drive by "why no merge?!?!?!" comments.
- Tepix 1y ago
  We need to work on decentralisation of git forges, making it less relevant where a project is hosted by offering cross-instance collaboration and discoverability.
gsich 1y ago

rrr_oh_man 1y ago

[flagged]

dtech 1y ago
If you had checked you would've seen issues are not enabled. I assume they still use their Bugzilla
- gbil 1y ago
  and they moved anyway the android firefox issues from github to bugzilla some time ago, it would be quite "funny" moving them back to github now
- rrr_oh_man 1y ago
  > If you had checked you would've seen issues are not enabled That was the point of the (obviously ill-received) joke.
  - calcifer 1y ago
    Ill-received or poorly stated? Try as I might, I can't find a joke in your comment.
    - nirava 1y ago
      I can. It was funny. No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once".
      - arp242 1y ago
        > No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once". Never underestimate the cynicism of HN commenters.

bandrami 1y ago

Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.

moralestapia 1y ago
Care to explain?
- aucisson_masque 1y ago
  Linus Torvalds invented git, which is what's used by GitHub and others like gitlab.
  - moralestapia 1y ago
    I know that, I just didn't get this part "and 20 years later we all use it to store our code in a single place". And as I can see here, no one else did ...
- joha4270 1y ago
  If GitHub went down, how much would it impact the open source world? Sure, there would be local copies everywhere, but for a distribution version control system, it's pretty centralized at GitHub
  - kgeist 1y ago
    If GitHub went down, the code would be fine (just announce a new official URL), but the main thing that would be lost is issues and pull requests. Maybe Git should add official support for issues and pull requests in its metadata to be fully decentralized.
    - nurumaik 1y ago
      Fully decentralized metadata so we can finally have merge conflicts in PR comments while discussing merge conflicts

IshKebab 1y ago

Not for PRs or issues though which are arguably the biggest reasons to use GitHub. Still this is definitely an improvement.

baq 1y ago
Which is fascinating since both suck. Gerrit (replace with whatever if you please) is a much better change submission experience and basically anything else is a better bug tracker. The killer feature is collocation of features to a single forge, combined with a generous free tier it’s the windows xp of the ecosystem: everybody has it, everybody knows it, almost nobody knows anything else.
matkv 1y ago
So is this now just a mirror? I'm not sure what the point of moving to GitHub was then.
- IshKebab 1y ago
  It's the primary repo rather than a mirror, but yeah I agree it they don't get most of the benefits. Moving issues and PRs is probably an enormous effort so I get why they aren't doing it all at once.
elric 1y ago
GitHub's issue tracker is easily the worst issue tracker I've ever used. It's at the same time incredibly limited in features, but somehow hard to navigate. As for PRs: I'm sure Mozilla welcome contributions, but accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage.
- IshKebab 1y ago
  Count yourself lucky you haven't had to use Jira! Or bugzilla for that matter. I agree it is rather basic but I don't see how it's hard to navigate. > accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage. I don't think that really happens based on what I've seen of other huge projects on GitHub.

deleted 1y ago

[deleted]

thrdbndndn 1y ago

Correct me if I'm wrong, IIRC the previous "master" branch is `mozilla-central`. Now it has "main" and "autoland", what are they? Which one is the equivalent of mozilla-central before?

chme 1y ago
Not a firefox dev, but pretty sure its 'main' The "new" git default branch name is 'main' and 'autoland' existed before next to 'mozilla-central' and is the one where commits usually appear first.
- jamienicol 1y ago
  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
  - thrdbndndn 1y ago
    Thanks for the clarification! I've mostly encountered these branches/repos when checking commits linked to Bugzilla tickets, and I don't recall seeing "autoland" show up too much in those cases.

mhh__ 1y ago

Inevitable. GitHub is a good platform in need of some proper dev workflows (pull requests are atrocious, branches footguns, yml driven CI is a noose) but they've obviously won.

jopsen 1y ago
I don't Firefox is moving to Github Actions anytime soon. I was pretty involved with the TaskCluster setup years ago, and it still seems to be running a bunch of CI things. mozilla-central has a LOT of tests -- each push burns a lot of compute hours.
- sfink 1y ago
  Yes. All CI is remaining in TaskCluster. Bugs are remaining in bugzilla, not GH issues. Code review is remaining in Phabricator (pre-Phorge fork), pushing in Lando (a custom layer). Some associated projects are using more GitHub stuff.

DennisL123 1y ago

A BUILD.md could be useful.

mdaniel 1y ago
the readme is literally 21 lines long, and about 25% of them are blank lines, with the 2nd URL pointing to "how to contribute" and that link has a dedicated "how to build and run" https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html#to-build-run https://firefox-source-docs.mozilla.org/contributing/contrib... The bad news is that their build system is extremely hand-rolled, and so if it works for you, count yourself lucky, because when it doesn't work you're in for 4 hours of python hell

floriangosse 1y ago

I think it's actually an understandable strategical move from Mozilla. They might loose some income from Google and probably have to cut the staff. But to keep the development of Firefox running they want to involve more people from the community and GitHub is the tool that brings most visibility on the market right now and is known by many developers. So the hurdle getting involved is much lower. I think you can dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.

fhd2 1y ago
In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.
- lpln3452 1y ago
  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?
  - Aachen 1y ago
    > what exactly is being lost by moving the repository to GitHub? Alternatives to github We lament Google's browser engine monopoly, but putting the vast majority of open source projects on github is just the expected course to take. I guess we'll repeat history once microsoft decides to set in the enshittification, maybe one day mobile OSes replace Windows and they're strapped for cash, who knows, but it's a centralised closed system owned by a corporation that absolutely adores FOSS I don't mind any particular project (such as this one) being in Github and I can understand that Mozilla chooses the easy path, they've got bigger problems after all, but it's not like there are no concerns with everyone and everything moving to github

mentalgear 1y ago

Would have been great if they used an European alternative ( like Codeberg ).

selectnull 1y ago
Mozilla is US organization, why would they care to?
- neilv 1y ago
  As for European specifically, maybe the commenter was talking about data protection laws. If not, maybe (in many European countries at the moment) less national or business background of ruthlessness. I was thinking something different: I wonder whether Mozilla considered GitLab or Codeberg, which are the other two I know that are popular with open source projects that don't trust GitHub since it sold out to Microsoft. (FWIW, Microsoft has been relatively gentle or subtle with GitHub, for whatever reason. Though presumably MS will backstab eventually. And you can debate whether that's already started, such as with pushing "AI" that launders open source software copyrights, and offering to indemnify users for violations. But I'd guess that a project would be pragmatically fine at least near term going with GitHub, though they're not setting a great example.)
  - selectnull 1y ago
    Given the Mozilla direction lately, the last thing they want is good data protection laws.
    - fsflover 1y ago
      This is a huge exaggeration, borderline dishonest attack.
      - selectnull 1y ago
        Time will tell. I would love to be wrong.

antalis 1y ago

Firefox Mobile (Fenix) had just moved to Mozilla's Mercurial mozilla-central repository after using GitHub including for issues. https://github.com/mozilla-mobile/firefox-android/wiki#upcoming-migration-to-mozilla-central https://github.com/mozilla-mobile/firefox-android/wiki#upcom... Now, both the desktop and the mobile version will be on Github, and the "issues" will stay on Bugzilla. This will take advantage of both GitHub's good search and source browsing and Git's familiar system. As a former Firefox and Thunderbird contributor, I have to say that I used local search instead of trying to find something on the mozilla-central website. Of course, when you're actively developing software, you search inside your IDE, but allowing to find things easily on the website makes it more welcoming for potential new contributors.

adrian17 1y ago
> I have to say that I used local search instead of trying to find something on the mozilla-central website. On the contrary, I find searchfox to be the best code navigation tool I used. It has nice cross-language navigation features (like jumping from .webidl interface definition to c++ implementation), it has always-on blame (with more features too) and despite that it's really fast and feels extremely lightweight compared to GitHub interface. I really wish I had this with more projects, and I'll be sad if it ever dies.
- antalis 1y ago
  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://discourse.mozilla.org/t/decommission-dxr/69475 https://billmccloskey.wordpress.com/2016/06/07/searchfox/ https://billmccloskey.wordpress.com/2016/06/07/searchfox/
baobun 1y ago
> This will take advantage of both GitHub's good search and source browsing and Git's familiar system. The source browsing has detoriated severely relatively recently IME, to the point where i can't be called "good" anymore. It now loads asynchronously (requiring js) and lazily, randomly breaks on shaky connections and in-page search is broken. The recent issues/PRs revamp is also a pretty major step back. Try searching in PRs with all uBlock Origin lists enabled.

tgsovlerkhgsel 1y ago

On one hand, centralization at a commercial provider isn't great. On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.

smallnix 1y ago
I wish I could search on GitHub without logging in
- nicce 1y ago
  They used to have 64 core 32 machine cluster just for search. You may want to reduce unnecessary search. https://github.blog/engineering/the-technology-behind-githubs-new-code-search/ https://github.blog/engineering/the-technology-behind-github...
  - mdaniel 1y ago
    This from a company that uses Ruby for their webapp and hosts probably one of the bigger CI build farms probably in the world. I have a very hard time crying because they have to run a beefy search cluster. I would guess that a very non-trivial portion of the horsepower for such a thing is about ingest of the constant updates moreso than the actual search part
- hedayet 1y ago
  I wish that too, and I’ve always wanted to offer features like this in everything I build. But it’s a lot of work to prevent abuse, especially for resource intensive features when supporting unsigned-in use cases.
elric 1y ago
> Just finding the repo is often a frustrating exercise Surely most open source projects have a link to their source code? Whether it's github, gitlab, sourcehut, or anything else?

rvz 1y ago

Centralizing everything to GitHub really isn't a good idea given their frequent incidents every week.

petepete 1y ago

I wonder how long it'll take for my PR which entirely removes the built in Pocket integration will take to be dismissed.

petepete 1y ago
Thankfully it won't be necessary!

mritzmann 1y ago

What is the source of “Firefox Moves to GitHub”? It could be a mirror, just like Linux also has an mirror on GitHub. https://github.com/torvalds/linux https://github.com/torvalds/linux // EDIT: Source: https://news.ycombinator.com/item?id=43970574 https://news.ycombinator.com/item?id=43970574

xrdev 1y ago
My thoughts as well, even more so after seeing the only GitHub Workflow they have is actually for closing Pull Requests with a default response: https://github.com/mozilla-firefox/firefox/blob/main/.github/workflows/close-pr.yml https://github.com/mozilla-firefox/firefox/blob/main/.github...
- sakjur 1y ago
  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.

octocop 1y ago

Nice, I was just checking yesterday to find the source code of firefox. Even if it is only a mirror it's a nice step to make it more available I think.

Kuinox 1y ago

It's good that they fixed one of the major tech debt for contributing to firefox. When I tried a few years ago, mercurial took multiple hours to clone, and I already had to use the unofficial git support in order to have things working before the end of the day. Their docs was also a mess back then and made me recompile everything even if it wasnt needed.

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 ago
Thanks for the added context. If I may - what were the significant scale challenges for self hosted solution?
- bayindirh 1y ago
  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 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.

kristel100 1y ago

Honestly surprised it took this long. For a project that depends so much on community contribution, being on GitHub just lowers the barrier for new devs. Curious to see if this revives contribution velocity.

berkes 1y ago
In the very least, it will open up FTEs that can now work on what makes Mozilla projects unique, rather than on building and maintaining generic fundamentals. It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.

roschdal 1y ago

Firefox moves to GitHub. Now someone better make a fork to make a proper web browser, small, fast, lean and without bloat and surveillance.

edelbitter 1y ago

So no IPv6 in the foreseeable future?

baobun 1y ago
It really is a bummer that we still can't clone over IPv6 in 2025. So annoying to have to set up (and pay for) IPv4 egress proxy on so many build systems and servers just because of this. https://github.com/orgs/community/discussions/10539 https://github.com/orgs/community/discussions/10539

bingemaker 1y ago

They already have an org github.com/mozilla. Why didn't they move ff source there?

nikolayasdf123 1y ago

nice, GitHub is defacto place to keep and release code

cubefox 1y ago

I assume this is now one of the largest (lines of code) projects on GitHub.

mdaniel 1y ago
I'd bet https://github.com/brave/brave-core https://github.com/brave/brave-core would top FF, since it's both chromium _and_ Brave's extra bits

mintplant 1y ago

Why is the mozilla-firefox org full of forks of the main repo named after trees? https://github.com/mozilla-firefox https://github.com/mozilla-firefox

dblohm7 1y ago
I haven't worked for Mozilla since 2021, but back then the branches named after trees were used as feature branches for large projects, at least until those projects were in a good enough state to cleanly merge back into trunk without breaking CI.
kbrosnan 1y ago
They are used for large scale landings or when a project needs to track trunk development but will churn a lot. https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectRepositories https://wiki.mozilla.org/ReleaseEngineering/DisposableProjec...

sylware 1y ago

Bad Move. github.com broke noscript/basic (x)html interop for most if not all core functions (which were working before). The issue system was broken not that long time ago. And one of the projects which should worry about, even enforce, such interop, moving to microsoft github... The internet world is a wild toxic beast.

zajio1am 1y ago

To me it seems absurd that such organization like Mozilla uses third-party hosting like GitHub instead of something self-hosted or at least running under their own name. I understand that one-person projects use GitHub, but forcing contributors to make account with third-party service seems contributor-hostile.

garganzol 1y ago
If it is an open source project then why not. This gives some visibility and welcoming openness to the project where everyone can contribute.

nolok 1y ago

I hope the bugzilla stay there even if only read only. There is a lot of historical data in there, especially for the web which was built as a "ad-hoc" platform, many times when you wonder why does X the answer can only be found in bugzilla (which will explain that some random website that used to be major but doesn't even exists anymore, did something for some browser that used to be major but doesn't even exists anymore).

fergie 1y ago
Bugzilla was really good, and in retrospect decades ahead of its time. There is probably no self hosted bug tracker that comes close (or it there?)
sfink 1y ago
Bugzilla is still the bug tracker for Firefox. I know if no plans to change that. (Github issues are not being used for the Firefox repo.)

upcoming-sesame 1y ago

Why did they choose the mozilla-firefox org as opposed to the already existing mozilla org ? https://github.com/mozilla https://github.com/mozilla

alpha_trion 1y ago
That's an excellent question
heftig 1y ago
Different access rules, I guess. Or maybe they wanted some separation from the existing org so the custom automation has no chance of doing collateral damage.

upcoming-sesame 1y ago

Why did they use mozilla-firefox org name instead of the already existing https://github.com/mozilla https://github.com/mozilla one ?

noobermin 1y ago

I guess the dream is dead. Even in open source, we have consolidation with no real hard monetary markets involved. EDIT: skimming these comments, I like how none of the top comments are talking about the bigger story here which is the move away from mercurial to git and instead everyone is focusing on github itself. This has essentially sealed hg away to obscurity forever. Do people not realise git is a program that runs on your computer and github is just a service that uses git? May be this is an old man gripe at this point but I'm surprised at the lack of technical discussion around this.

dzaima 1y ago
This is far from the first project to move from hg to git; many people probably just generally expect that to happen upon any source code management change for anything still using mercurial, which has already been effectively dead for most people for years.
- noobermin 1y ago
  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.
garganzol 1y ago
I cannot imagine moving to Git from Mercurial. Git looks clunky from my perspective. Yes, it works too, but working with Git is a usability torture, sorry but it is true. I like some Git features better though, but not most of them.
- static_motion 1y ago
  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?

elmer007 1y ago

Star Wars reference in a comment: https://github.com/mozilla-firefox/firefox/blob/917c73cfe1a5b7d78bf163edbd9b471563088192/modules/libmar/src/mar_create.c#L255 https://github.com/mozilla-firefox/firefox/blob/917c73cfe1a5... Fun to get a glimpse into someone's thought process while they were working.

thund 1y ago

Hate seeing how repos are so polluted by dot-files and dot-folders. I wish tools and SDKs converged into a single dot-folder, so that we could look at repos without seeing everything everywhere

metalliqaz 1y ago

What are 'pine', 'maple', 'holly', etc?

hanlonsrazor 1y ago
Internal nomenclature for feature branches.

InTheArena 1y ago

as a side note - I love the new bookmark tabs feature. About time :-)

frshOffTheBoat 1y ago

[dead]

deleted 1y ago

[deleted]

kidsil 1y ago

First commit: https://github.com/mozilla-firefox/firefox/commit/c4cc52826abd53e1121e4234d719cfd89ce58093 https://github.com/mozilla-firefox/firefox/commit/c4cc52826a... Hard to believe it's been 27 years. I remember when it was still in beta, and how exciting it was to have an open source alternative to Internet Explorer. Good times!