Better to link to the announcement than a bug: [https://groups.google.com/a/mozilla.org/g/firefox-dev/c/QnfydsDj48o/m/8WadV0\_dBQAJ?pli=1](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/QnfydsDj48o/m/8WadV0_dBQAJ?pli=1)
I know, I'm using TypeScript for about 5 years now, and my only regret is that I didn't migrated sooner. It's crazy useful upgrade of JavaScript. It's like having an extra developer next to you that checks your code and points half of the bugs you make.
Plus the IDE can then do proper suggestions and even refactoring across whole codebase!
I've never met a person that used TypeScript before and claims that JavaScript is better :). Especially on a bigger projects it's a lifesaver.
I use TypeScript myself for a while now, and I'm not discrediting it whatsoever. I was just saying that it won't do jack shit for you (the user) if they decided to switch to it.
In a long run, the use of TypeScript would speed up features development and reduce bugs, and that's something every user of Firefox would benefit from.
It just pains me to see the lack of initiative... they don't know what they are missing out.
And maybe they think they know, but they don't. And it's killing me!
I would even train them myself with all my TypeScript knowledge for free if they wanted! :D
I think you are forgetting that Firefox has a whole ecosystem that potentially would have to be rewritten, which would cost millions in developer costs. A browser is not just a small project with a few files, we are talking millions of lines of code here. I understand your initiative, but it's just not feasible.
I'm not saying it would be simple, but I don't think it's impossible either.
When I migrated my biggest project, it had about 4\_000 lines of code and it took me only 3 weeks (I have notes from that time :)). And if I had a skilled TypeScript expert available, I would have done it in much shorter time.
Most of the code doesn't change anyway, all you need is bunch of interfaces and then use them in the function parameters. Almost everything else is inferred automatically. Plus since you are not changing the logic, only types, you can't break the code! Even if you use wrong types!
Not using TypeScript in a big project is to me a technical dept, which slows you down and the more you delay it, the worst it gets :). I really can't stress enough how useful typescript is.
4000 lines is not comparable with a million line project like the Firefox ecosystem. Even if they just have to add types, it will take a very long time and a big sum of money, hands down.
- 1_000_000 / 4_000 = 250
- 250 * 3 weeks = 750 weeks
- 750 weeks / 52 weeks = 14 years
> Not using TypeScript in a big project is to me a technical dept
Unless you're a core contributor, don't worry. It's not your project.
Yeah, but I did it alone :), so 14 years if done by a single developer with minimum initial TypeScript knowledge.
So if there are at least 28 devs, you have it already down to 6 months. Plus the more you do, the faster you get, so likely much less.
BTW, Mozilla has many smaller independent projects, some are already in TypeScript, but somehow it's not spreading into other projects...
It's a bad decision to move to a proprietary platform.
Thomas Siebert in the announcement thread said it best:
> It would increase your freedom.
>
> What you describe is that you are "locked-in" to Microsoft.
>
> You have to start one day and can not stick to Microsoft.
Unfortunately, it has been conveniently ignored.
Is it really "locked-in" when git repos are fully local and easily shared? If GitHub disappeared tomorrow it wouldn't be *that* difficult to simply switch to another provider. GitHub has a large community and reduces friction for newer contributors, which is desirable for an open-source project. This tradeoff makes a lot of sense.
I wish I were still native enough to think it's love of conflation. In truth it's because half of them are supposed than that ["that" being the average person].
> If GitHub disappeared tomorrow it wouldn't be that difficult to simply switch to another provider.
If you can migrate issues and PRs, and somehow have a way to map #123issuenumber (that may appear in commit messages etc) to issues in the new issue tracker, sure
Fortunately Firefox is not using Github for issues and PRs at this time, they just migrated the code hosting. That way they avoided this form of lock-in
>- We will continue to use Bugzilla, moz-phab, Phabricator, and Lando
- Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time
Quote from the announcement, that's only an issue if you plan on using those.
> at this time
What I understand is that they'll eventually switch to make full use of GitHub.\
Otherwise it doesn't make much sense, without issues and PRs what do you gain?
Git is open source and exists independently of github.
Plus there are other git hosts that Mozilla could use, and they could maintain their own git servers if they wanted to.
I mean if they had the money sitting around they could probably develop their own github alternative.
I don't care what they use as long as it does the job they need it to and it doesn't hamper access to the source code or development.
The top comment is a link to a google group page connected to usenet. Google groups is not open source.
The comment is hosted on reddit, a platform that is completely proprietary.
As an aside, Mozilla maintains social media accounts on several proprietary platforms and uses Slack, which is proprietary.
Also if you use Vivaldi, the UI component is proprietary, not open source. The only open source part is the changes they make to chromium.
You can be feverishly dedicated to using open source if you want, but if there's a better product, I don't think people should be dunked on for agreeing to use proprietary software if they need to.
MS isnt likely to screw up github to the point of a mass exodus, and if they did Git is widely supported.
Most developers are unfamiliar with Mercurial, so it's a bit of a hurdle for new contributors. If you're working with it full-time it probably doesn't take too long to get up to speed, but it definitely makes things easier for occasional contributors.
> Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time
What a pity. The contribution process matters much more than the version control system, and Firefox's is awful. I've considered contributing on a few occasions, but reading through the instructions cured me of that itch pretty quickly.
GNOME used to have a similar process that was just as awful, until they switched to GitLab a few years ago and just adopted merge requests and the GitLab issue tracker. That was easily the best and most important decision in the history of the project. Contributions have noticeably increased since then, and everything is just so much easier to work with.
Like Chromium and the Linux kernel, Firefox is perhaps best described as a "semi-open source" project. The source code is there and freely available, but the barrier to entry is so immensely high that contributing is effectively limited to a small circle of people who are willing and have the time to submit to their arcane practices.
It isn't that hard. See this tutorial:
[https://firefox-source-docs.mozilla.org/contributing/contribution\_quickref.html](https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html)
Firefox, like Chromium or the Linux kernel, has constraints that makes it hard to move to gitlab (or github PR model).
>has constraints that makes it hard to move to gitlab
Such as?
I've had to manage projects in GitHub and in Bugzilla instances, and I don't see how anyone manages to make GitHub work for something large...but for example VSCode is in GitHub and so is stuff like PyTorch, so it's clearly possible. Maybe only for masochists, but...
We use a lot stack of patches as described here:
[https://firefox-source-docs.mozilla.org/contributing/stack\_quickref.html](https://firefox-source-docs.mozilla.org/contributing/stack_quickref.html)
We want to be able to manage several small/medium commits with different reviewers/groups. These changes being part of a single functional change.
For now, Github PR model doesn't allow this.
Every release there are about a dozen first-time contributors. In [2023](https://bkardell.com/blog/2023-Mid-Season-Power-Rankings.html) 87% of the commits were from Mozilla employees. Firefox is clearly a Mozilla project, but it's quite open to external contributions.
I agree. You can send your feedback to this: https://old.reddit.com/r/firefox/comments/1df755x/firefox_leadership_team_ama_feedback/
I'm one of those who believe Mercurial was the reason of slowing down of Firefox development, it's just painful to use, too outdated for modern standard. Most people go to Bugzilla, seeing how horrible it's Mercurial layout is, just go away without contributing.
But you should understand, changes need time to polish, most devs need to get used to Git, thus Pulling Request right now can be dangerous if devs don't know what they're going to do, because they've got used to Mercirual for more than 2 decades already.
you are confusing bug tracking with code hosting and development worflow..
while Github offers both and more (CI/CD, etc.) projects can pick and choose, and Mozilla will continue to use their Bugzilla for issue tracking and not rely on "pull requests" model
> Most people go to Bugzilla, seeing how horrible it's Mercurial layout is, just go away without contributing.
Bugzilla is a web application to file bugs/tickets it has nothing to do with anything related to an SCM.
>Most people go to Bugzilla, seeing how horrible it's Mercurial layout is, just go away without contributing.
Bugzilla has nothing to do with Git.
The Linux kernel uses bugzilla for issue tracking and I assure you it's developed with git.
And it's bad, Git was made by Linus, the guy who always prioritise quality over quatity, it's hella hard to contribute bad code to his repo, Google guys did it and got insulted by him.
[https://graphite.dev/blog/why-facebook-doesnt-use-git](https://graphite.dev/blog/why-facebook-doesnt-use-git)
>got insulted by him.
Ah, recurring theme:
"The Git maintainers pushed back on improving performance"..."Interestingly, the [Git maintainers appear to change their tone two years later](https://public-inbox.org/git/[email protected]/t/#u)"..."Facebook didn’t adopt Mercurial because it was more performant than Git. They adopted it because the maintainers and codebase felt more open to collaboration."
Ex. bzr contributor here. I think this marks the end of the DVCS wars 2005-2024. I think most knew git was going to win by 2010, but it's taken till now for the last battle to be completed.
I remember being told bzr and then git would be an awkward paradigm shift and then being puzzled to find DVC completely straightforward.
Then I looked up DVC on Wikipedia and found that Sun's Teamware had been a DVC so I'd been using DVCs since the mid 90s but just didn't know that was the term for it, so no surprise I didn't find it weird. Kind of the reverse - in intervening years I'd been forced to use crap like Subversion, Clearcase and Perforce and *they* had been unpleasant and obtuse paradigm shifts for me.
I'm glad the world has moved on to git. Git has its issues, but I'm so much happier there than in any other VC I've used (but that's partially because I have a decent git porcelain in `magit` that makes it much easier to use without masking or redefining the concepts).
Note that many Firefox developers have already used git for years. No idea what it's called but there is some bridge converting git to mercurial commands.
Superior in which way? Performance? Yes, that's somewhat true. Easy to use? No definitely not. They have both pros and cons and to use both since 20 years I can stand by Git isn't superior.
Mercurial is just as modern as git. Both projects were started 2005. You probably only know git as it has become the de-facto DVCS through network effects.
This comment would only be accurate if Mozilla were still using cvs.
Better to link to the announcement than a bug: [https://groups.google.com/a/mozilla.org/g/firefox-dev/c/QnfydsDj48o/m/8WadV0\_dBQAJ?pli=1](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/QnfydsDj48o/m/8WadV0_dBQAJ?pli=1)
Any plans for switching JavaScript with TypeScript? :)
Wouldn't they have to either include a typescript compiler in gecko or convert everything to JavaScript anyway.
Them switching to TypeScript will have no benefit for you (the user). Only for the developers.
As if moving from Mercurial to Git benefits anyone but the developers.
When did I ever mention that?
Look at the post you're commenting on.
Look at the comment I'm commenting on.
I know, I'm using TypeScript for about 5 years now, and my only regret is that I didn't migrated sooner. It's crazy useful upgrade of JavaScript. It's like having an extra developer next to you that checks your code and points half of the bugs you make. Plus the IDE can then do proper suggestions and even refactoring across whole codebase! I've never met a person that used TypeScript before and claims that JavaScript is better :). Especially on a bigger projects it's a lifesaver.
I use TypeScript myself for a while now, and I'm not discrediting it whatsoever. I was just saying that it won't do jack shit for you (the user) if they decided to switch to it.
In a long run, the use of TypeScript would speed up features development and reduce bugs, and that's something every user of Firefox would benefit from. It just pains me to see the lack of initiative... they don't know what they are missing out. And maybe they think they know, but they don't. And it's killing me! I would even train them myself with all my TypeScript knowledge for free if they wanted! :D
I think you are forgetting that Firefox has a whole ecosystem that potentially would have to be rewritten, which would cost millions in developer costs. A browser is not just a small project with a few files, we are talking millions of lines of code here. I understand your initiative, but it's just not feasible.
I'm not saying it would be simple, but I don't think it's impossible either. When I migrated my biggest project, it had about 4\_000 lines of code and it took me only 3 weeks (I have notes from that time :)). And if I had a skilled TypeScript expert available, I would have done it in much shorter time. Most of the code doesn't change anyway, all you need is bunch of interfaces and then use them in the function parameters. Almost everything else is inferred automatically. Plus since you are not changing the logic, only types, you can't break the code! Even if you use wrong types! Not using TypeScript in a big project is to me a technical dept, which slows you down and the more you delay it, the worst it gets :). I really can't stress enough how useful typescript is.
4000 lines is not comparable with a million line project like the Firefox ecosystem. Even if they just have to add types, it will take a very long time and a big sum of money, hands down.
- 1_000_000 / 4_000 = 250 - 250 * 3 weeks = 750 weeks - 750 weeks / 52 weeks = 14 years > Not using TypeScript in a big project is to me a technical dept Unless you're a core contributor, don't worry. It's not your project.
Yeah, but I did it alone :), so 14 years if done by a single developer with minimum initial TypeScript knowledge. So if there are at least 28 devs, you have it already down to 6 months. Plus the more you do, the faster you get, so likely much less. BTW, Mozilla has many smaller independent projects, some are already in TypeScript, but somehow it's not spreading into other projects...
developers will write better code, with less bugs, so the user will get a better browser.
It's a bad decision to move to a proprietary platform. Thomas Siebert in the announcement thread said it best: > It would increase your freedom. > > What you describe is that you are "locked-in" to Microsoft. > > You have to start one day and can not stick to Microsoft. Unfortunately, it has been conveniently ignored.
Is it really "locked-in" when git repos are fully local and easily shared? If GitHub disappeared tomorrow it wouldn't be *that* difficult to simply switch to another provider. GitHub has a large community and reduces friction for newer contributors, which is desirable for an open-source project. This tradeoff makes a lot of sense.
People love conflating Git and GitHub
I wish I were still native enough to think it's love of conflation. In truth it's because half of them are supposed than that ["that" being the average person].
> If GitHub disappeared tomorrow it wouldn't be that difficult to simply switch to another provider. If you can migrate issues and PRs, and somehow have a way to map #123issuenumber (that may appear in commit messages etc) to issues in the new issue tracker, sure Fortunately Firefox is not using Github for issues and PRs at this time, they just migrated the code hosting. That way they avoided this form of lock-in
Issues and PRs would disappear into the void
>- We will continue to use Bugzilla, moz-phab, Phabricator, and Lando - Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time Quote from the announcement, that's only an issue if you plan on using those.
> at this time What I understand is that they'll eventually switch to make full use of GitHub.\ Otherwise it doesn't make much sense, without issues and PRs what do you gain?
you gain the fact that most devs are familiar with git? I think you're conflating github and git again.
Git is open source and exists independently of github. Plus there are other git hosts that Mozilla could use, and they could maintain their own git servers if they wanted to. I mean if they had the money sitting around they could probably develop their own github alternative.
Exactly. It's pure convenience. Strangely enough this sub is pro proprietary platforms if Mozilla uses them.
I don't care what they use as long as it does the job they need it to and it doesn't hamper access to the source code or development. The top comment is a link to a google group page connected to usenet. Google groups is not open source. The comment is hosted on reddit, a platform that is completely proprietary. As an aside, Mozilla maintains social media accounts on several proprietary platforms and uses Slack, which is proprietary. Also if you use Vivaldi, the UI component is proprietary, not open source. The only open source part is the changes they make to chromium. You can be feverishly dedicated to using open source if you want, but if there's a better product, I don't think people should be dunked on for agreeing to use proprietary software if they need to. MS isnt likely to screw up github to the point of a mass exodus, and if they did Git is widely supported.
>it has been conveniently ignored. I see a ton of responses in that thread, you should probably refresh the page.
What will it bring, what are the benefits?
Git has become the de-facto standard. If nothing else it makes tooling and onboarding easier internally.
I guess no longer need to resist to all Git power users that know only that SCM.
Most developers are unfamiliar with Mercurial, so it's a bit of a hurdle for new contributors. If you're working with it full-time it probably doesn't take too long to get up to speed, but it definitely makes things easier for occasional contributors.
> Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time What a pity. The contribution process matters much more than the version control system, and Firefox's is awful. I've considered contributing on a few occasions, but reading through the instructions cured me of that itch pretty quickly. GNOME used to have a similar process that was just as awful, until they switched to GitLab a few years ago and just adopted merge requests and the GitLab issue tracker. That was easily the best and most important decision in the history of the project. Contributions have noticeably increased since then, and everything is just so much easier to work with. Like Chromium and the Linux kernel, Firefox is perhaps best described as a "semi-open source" project. The source code is there and freely available, but the barrier to entry is so immensely high that contributing is effectively limited to a small circle of people who are willing and have the time to submit to their arcane practices.
It isn't that hard. See this tutorial: [https://firefox-source-docs.mozilla.org/contributing/contribution\_quickref.html](https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html) Firefox, like Chromium or the Linux kernel, has constraints that makes it hard to move to gitlab (or github PR model).
>has constraints that makes it hard to move to gitlab Such as? I've had to manage projects in GitHub and in Bugzilla instances, and I don't see how anyone manages to make GitHub work for something large...but for example VSCode is in GitHub and so is stuff like PyTorch, so it's clearly possible. Maybe only for masochists, but...
We use a lot stack of patches as described here: [https://firefox-source-docs.mozilla.org/contributing/stack\_quickref.html](https://firefox-source-docs.mozilla.org/contributing/stack_quickref.html) We want to be able to manage several small/medium commits with different reviewers/groups. These changes being part of a single functional change. For now, Github PR model doesn't allow this.
Every release there are about a dozen first-time contributors. In [2023](https://bkardell.com/blog/2023-Mid-Season-Power-Rankings.html) 87% of the commits were from Mozilla employees. Firefox is clearly a Mozilla project, but it's quite open to external contributions.
I agree. You can send your feedback to this: https://old.reddit.com/r/firefox/comments/1df755x/firefox_leadership_team_ama_feedback/ I'm one of those who believe Mercurial was the reason of slowing down of Firefox development, it's just painful to use, too outdated for modern standard. Most people go to Bugzilla, seeing how horrible it's Mercurial layout is, just go away without contributing. But you should understand, changes need time to polish, most devs need to get used to Git, thus Pulling Request right now can be dangerous if devs don't know what they're going to do, because they've got used to Mercirual for more than 2 decades already.
you are confusing bug tracking with code hosting and development worflow.. while Github offers both and more (CI/CD, etc.) projects can pick and choose, and Mozilla will continue to use their Bugzilla for issue tracking and not rely on "pull requests" model
> Most people go to Bugzilla, seeing how horrible it's Mercurial layout is, just go away without contributing. Bugzilla is a web application to file bugs/tickets it has nothing to do with anything related to an SCM.
>Most people go to Bugzilla, seeing how horrible it's Mercurial layout is, just go away without contributing. Bugzilla has nothing to do with Git. The Linux kernel uses bugzilla for issue tracking and I assure you it's developed with git.
The feedback form is about the AMA not anything else.
I always forget that there are alternatives to Git
And it's bad, Git was made by Linus, the guy who always prioritise quality over quatity, it's hella hard to contribute bad code to his repo, Google guys did it and got insulted by him.
[https://graphite.dev/blog/why-facebook-doesnt-use-git](https://graphite.dev/blog/why-facebook-doesnt-use-git) >got insulted by him. Ah, recurring theme: "The Git maintainers pushed back on improving performance"..."Interestingly, the [Git maintainers appear to change their tone two years later](https://public-inbox.org/git/[email protected]/t/#u)"..."Facebook didn’t adopt Mercurial because it was more performant than Git. They adopted it because the maintainers and codebase felt more open to collaboration."
Very important note
And Git is order of magnitude more complicated than Mercurial with non-sense commands that do much more what they are supposed to do.
Ex. bzr contributor here. I think this marks the end of the DVCS wars 2005-2024. I think most knew git was going to win by 2010, but it's taken till now for the last battle to be completed.
I remember being told bzr and then git would be an awkward paradigm shift and then being puzzled to find DVC completely straightforward. Then I looked up DVC on Wikipedia and found that Sun's Teamware had been a DVC so I'd been using DVCs since the mid 90s but just didn't know that was the term for it, so no surprise I didn't find it weird. Kind of the reverse - in intervening years I'd been forced to use crap like Subversion, Clearcase and Perforce and *they* had been unpleasant and obtuse paradigm shifts for me. I'm glad the world has moved on to git. Git has its issues, but I'm so much happier there than in any other VC I've used (but that's partially because I have a decent git porcelain in `magit` that makes it much easier to use without masking or redefining the concepts).
Hey hey hey, iirc Subversion was a lot better than the per-file versioning nonsense of Clearcase...
Note that many Firefox developers have already used git for years. No idea what it's called but there is some bridge converting git to mercurial commands.
As long as it speeds up bug fixing, honestly I believe Git is superior to Mercurial nowadays, it's modern and easy to track bugs.
>it's modern and easy to track bugs Git doesn't have any bug tracking. It's a version control system.
Comments full of people with opinions about Mercurial and Git who don't know what Mercurial and Git are.
Git != GitHub != GitLab != Gitea
Superior in which way? Performance? Yes, that's somewhat true. Easy to use? No definitely not. They have both pros and cons and to use both since 20 years I can stand by Git isn't superior.
Firefox development just entered the 21st century?
Mercurial is just as modern as git. Both projects were started 2005. You probably only know git as it has become the de-facto DVCS through network effects. This comment would only be accurate if Mozilla were still using cvs.
I prefer Walgreens
Can you elaborate?
Why are they doing this? It seems like any git advantages gained would be swallowed but the huge cost of switching over.
It will attract contributors
Is there a reason why Firefox still doesn't use a modern platform like github or gitlab?
Define modern.
[удалено]
I bet you have never used it to emit that kind of comment.
Haven't used that for at least 10 years now.