Most active commenters
  • bayindirh(5)
  • fsflover(5)
  • jgraham(4)
  • lupusreal(3)
  • dspillett(3)
  • LadyCailin(3)
  • baobun(3)
  • hedora(3)

←back to thread

848 points thefilmore | 89 comments | | HN request time: 0.674s | source | bottom
1. jgraham ◴[] No.43970574[source]
(I work at Mozilla, but not on the VCS tooling, or this transition)

To give a bit of additional context here, since the link doesn't have any:

The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI.

In the short term the mercurial servers still exist, and are synced from GitHub. That allows automated systems to transfer to the git backend over time rather than all at once. Mercurial is also still being used for the "try" repository (where you push to run CI on WIP patches), although it's increasingly behind an abstraction layer; that will also migrate later.

For people familiar with the old repos, "mozilla-central" is mapped onto the more standard branch name "main", and "autoland" is a branch called "autoland".

It's also true that it's been possible to contribute to Firefox exclusively using git for a long time, although you had to install the "git cinnabar" extension. The choice between the learning hg and using git+extension was a it of an impediment for many new contributors, who most often knew git and not mercurial. Now that choice is no longer necessary. Glandium, who wrote git cinnabar, wrote extensively at the time this migration was first announced about the history of VCS at Mozilla, and gave a little more context on the reasons for the migration [1].

So in the short term the differences from the point of view of contributors are minimal: using stock git is now the default and expected workflow, but apart from that not much else has changed. There may or may not eventually be support for GitHub-based workflows (i.e. PRs) but that is explicitly not part of this change.

On the backend, once the migration is complete, Mozilla will spend less time hosting its own VCS infrastructure, which turns out to be a significant challenge at the scale, performance and availability needed for such a large project.

[1] https://glandium.org/blog/?p=4346

replies(5): >>43970669 #>>43971472 #>>43971745 #>>43974450 #>>43974555 #
2. iamcreasy ◴[] No.43970669[source]
Thanks for the added context.

If I may - what were the significant scale challenges for self hosted solution?

replies(3): >>43970862 #>>43970906 #>>43976364 #
3. bayindirh ◴[] No.43970862[source]
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.

replies(3): >>43970890 #>>43970919 #>>43970938 #
4. notpushkin ◴[] No.43970890{3}[source]
I think the CI/CD infra stays intact here though? (and even then, I imagine GitHub Actions bill would be enormous for a project like Firefox)
replies(2): >>43970925 #>>43971425 #
5. jgraham ◴[] No.43970906[source]
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...

replies(2): >>43971007 #>>43977390 #
6. arp242 ◴[] No.43970919{3}[source]
> I guess it's the CI/CD infrastructure

Your guess is wrong as Firefox doesn't use GitHub for any of that, and AFAIK there are no plans to either.

The blog post linked in the top comment goes in to this in some detail, but in brief: git log, clone, diff, showing files, blame, etc. is CPU expensive. You can see this locally on large repo if you try something like "git log path/to/dir".

Add to this all the standard requirements of running any server that needs to be 1) fast, and 2) highly available.

And why bother when there's a free service available for you?

replies(1): >>43970931 #
7. bayindirh ◴[] No.43970925{4}[source]
I think it can be done half/half. Do some, well-defined builds at GitHub and pull in for testing. Another comment tells that some users needed 10+ minutes to get a lock to pass their tests through CI, so maybe some sanity tests can be offloaded to GitHub actions.

I'm not claiming that my comment was 100% accurate, but they plan to move some of the CI to GitHub, at least.

replies(1): >>43971467 #
8. bayindirh ◴[] No.43970931{4}[source]
It was a guess and I never claimed it was 100% correct, and I'm happy to stand corrected. No hard feelings there.
replies(1): >>43971183 #
9. jgraham ◴[] No.43970938{3}[source]
This is all true, but as the sibling says, not really related to the change discussed here.

Firefox does indeed have a large CI system and ends up running thousands of jobs on each push to main (formerly mozilla-central), covering builds, linting, multiple testsuites, performance testing, etc. all across multiple platforms and configurations. In addition there are "try" pushes for work in progress patches, and various other kinds of non-CI tasks (e.g. fuzzing). That is all run on our taskcluster system and I don't believe there are any plans to change that.

10. monegator ◴[] No.43971007{3}[source]
why github and not codeberg? badwidth? $$$ from microsoft? (traffic, free training for copilot, ..)
replies(6): >>43971085 #>>43971120 #>>43971319 #>>43971424 #>>43972405 #>>43973600 #
11. Macha ◴[] No.43971085{4}[source]
I'm not sure codeberg has managed two 9s of uptime while I've been using it. Manageable when it's just a public mirror for occasional publishing of my small hobby projects, but I wouldn't recommend it for Firefox sized projects
replies(3): >>43971343 #>>43973427 #>>43981144 #
12. Slartie ◴[] No.43971120{4}[source]
I'm pretty sure that Copilot already saw the Firefox source code, and that they didn't have to wait for Firefox moving to GitHub for that.
13. tempaccount420 ◴[] No.43971183{5}[source]
"I guess..." != "I'm guessing..."
replies(1): >>43971406 #
14. GuB-42 ◴[] No.43971319{4}[source]
I would say that using GitHub only for a public git repository is pretty good value.

It is free and robust, and there is not much bad Microsoft can do to you. Because it is standard git, there is no lockdown. If they make a decision you don't like, migrating is just a git clone. As for the "training copilot" part, it is public, it doesn't change anything that Microsoft hosts the project on their own servers, they can just get the source like anyone else, they probably already do.

Why not Codeberg? I don't know, maybe bandwidth, but if that's standard git, making a mirror on Codeberg should be trivial.

That's why git is awesome. The central repository is just a convention. Technically, there is no difference between the original and the clone. You don't even need to be online to collaborate, as long as you have a way to exchange files.

replies(2): >>43971550 #>>43974654 #
15. Miaourt ◴[] No.43971343{5}[source]
Maybe if Mozilla gave one hundredth of their CEO's salary in donation to Codeberg they would be more than happy and able to scale to nine nine :p
replies(1): >>43971396 #
16. prepend ◴[] No.43971396{6}[source]
Maybe. Maybe not. If I was the person responsible for the code, I wouldn’t want to gamble on them becoming good enough for me to use.
replies(1): >>43971662 #
17. bayindirh ◴[] No.43971406{6}[source]
That's new to me. Can you expand on that a little?
18. jorvi ◴[] No.43971424{4}[source]
Why did you omit (self-hosted) gitlab..?
replies(1): >>43971519 #
19. saghm ◴[] No.43971425{4}[source]
If the CI/CD is the most intensive part, it seems reasonable to move all of the other parts to a free provider to focus on the part that would be harder and more expensive to move. Even if they don't ever move any of the CI/CD over, I feel like I can understand the rationale for reducing the scope to just that rather than the source hosting. I've worked on plenty of projects with way less traffic than Firefox over the years that used GitHub for source hosting but alternate CI/CD; GitHub didn't even have built in CI for a while, so that was the only way to use it.

Given the frequency I see comments on this site about Mozilla trying to do far too much rather than just focusing their efforts on core stuff like Firefox, I'm honestly a bit surprised that there aren't more people agreeing with this decision. Even with the other issues I have with Mozilla lately (like the whole debacle over the privacy policy changes and the extremely bizarre follow-up about what the definition of "selling user data" is), I don't see it as hypocritical to use GitHub while maintaining a stance that open solutions are better than closed ones because I think trying to make an open browser in the current era is a large and complicated goal for it to be worth it to set a high bar for taking on additional fights. Insisting on spending effort on maintaining their own version control servers feels like a effort that they don't need to be taking on right now, and I'd much rather than Mozilla pick their battles carefully like this more often than less. Trying to fight for more open source hosting at this point is a large enough battle that maybe it would make more sense for a separate organization focused on that to be leading the front in that regard; providing an alternative to Chrome is a big enough struggle that it's not crazy for them to decide that GitHub's dominance has to be someone else's problem.

replies(1): >>43972511 #
20. TheDong ◴[] No.43971467{5}[source]
> but they plan to move some of the CI to GitHub, at least

Really? I've seen no indication of that anywhere, and I'd be amazed if they did.

They're not using github PRs, and github actions really fights against other development workflows... not to mention they already have invested a lot in TaskCluster, and specialized it to their needs.

Where are you getting that from?

replies(1): >>43971767 #
21. lupusreal ◴[] No.43971472[source]
> This only affects the code; bugzilla is still being used for issue tracking

Grim.

The best reason to be using github at all is to maximize the portion of your users who are comfortable submitting bug reports, as they already have an account and are familiar with how the platform works (due to network effects.) Projects which host code on github but chose not to take bug reports there are effectively gate keeping bug submission, by asking their users to jump through the hoops of finding the site, signing up for it, and learning to use a new interface. I've done this before, with Bugzilla and Firefox, to submit a bug report for an accessibility bug on MacOS and it was a pain in the ass that I put off for a long time before becoming annoyed enough to go through the process. (End result: the bug was confirmed but never fixed..)

replies(5): >>43971541 #>>43971614 #>>43971672 #>>43972086 #>>43973634 #
22. dspillett ◴[] No.43971519{5}[source]
[not OP, but making educated guesses from what has already been said]

Given the post above, issues regarding self-hosting were at least part of the reason for the switch so a new self-hosted arrangement is unlikely to have been considered at all.

I don't know what the state of play is right now, but non-self-hosted GitLab has had some notable performance issues (and, less often IIRC, availability issues) in the past. This would be a concern for a popular project with many contributors, especially one with a codebase as large as Firefox.

23. dspillett ◴[] No.43971541[source]
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? :-)

replies(1): >>43972847 #
24. immibis ◴[] No.43971550{5}[source]
I am banned from GitHub because I didn't want to give them my phone number. They ignored a legally binding GDPR request to delete all my data. I haven't got around to suing them yet.

Recently I also got "rate limited" after opening about three web pages.

Microsoft can do something to you, and that is to arbitrarily deny you access after you've built a dependence on it, and then make you jump through hoops to get access back.

replies(5): >>43971753 #>>43971894 #>>43972095 #>>43973248 #>>43980513 #
25. matkoniecz ◴[] No.43971614[source]
I suspect that Firefox is not bottlenecked on number of bug reports they got.
replies(1): >>43972908 #
26. executesorder66 ◴[] No.43971662{7}[source]
Yeah, it's not like they care about improving the state of the open source ecosystem anyway.
27. jgraham ◴[] No.43971672[source]
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.

28. emigre ◴[] No.43971745[source]
Thanks for the context. IMHO I don't think Mozilla should have decided to move to a closed-source platform owned by Microsoft.
replies(1): >>43971801 #
29. LadyCailin ◴[] No.43971753{6}[source]
This is kind of a weird hill to die on, but you’re well within your rights, so you do you.

However, it is clearly not correct to say that you were banned from GitHub. It’s like saying “I was banned from Google because I refuse to use computing devices.”

Not really a ban, just self flagellation, which, again, whatever works for you.

replies(2): >>43971900 #>>43974101 #
30. bayindirh ◴[] No.43971767{6}[source]
It was an, apparently very wrong, educated guess. Nothing more.
31. fguerraz ◴[] No.43971801[source]
Thanks to the decentralised nature of git, this should matter only moderately.
replies(3): >>43972206 #>>43976791 #>>43983534 #
32. alabastervlog ◴[] No.43971894{6}[source]
> Recently I also got "rate limited" after opening about three web pages.

People who haven’t used it logged out recently may be surprised to find that they have, for some time, made the site effectively unusable without an account. Doing one search and clicking a couple results gets you temporarily blocked. It’s effectively an account-required website now.

replies(5): >>43973386 #>>43973491 #>>43973618 #>>43974008 #>>43986761 #
33. immibis ◴[] No.43971900{7}[source]
Give me your social security number or you may not reply to my comments. If you don't give me your social security number, choosing instead to die on this weird hill, it's not correct to say you're banned - you're merely self-flagellating.
replies(2): >>43974590 #>>43977341 #
34. AlienRobot ◴[] No.43972086[source]
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.
replies(2): >>43972649 #>>43974488 #
35. baobun ◴[] No.43972095{6}[source]
At least you had the choice. Many potential contributors live in countries to which GitHub does not support SMS verification but still requires it. So there's a second tier of effectively blocked countries besides the officially sanctioned ones.
36. JeremyNT ◴[] No.43972206{3}[source]
Exactly, now they have the best of both worlds: let Microsoft host the code using a standard VCS, but avoid lock in by continuing to use their own issue tracker and project management software.
replies(1): >>43974759 #
37. freeopinion ◴[] No.43972405{4}[source]
I had a similar thought. I am disappointed that Mozilla didn't take some of the money they were spending on a self-hosted homegrown solution and throw it to something like Codeberg. I guess that a little funding from the likes of Mozilla could go a long way in helping Forgejo pioneer some super interesting federation.

Of course Mozilla is free to make their own choices. But this choice will be read as the latest alarm bell for many already questioning the spirit of Mozilla management.

38. notpushkin ◴[] No.43972511{5}[source]
Yeah, I agree that everything that helps reduce maintenance overhead is good for Mozilla (although I believe there’s more low-hanging fruits that could be addressed before that).

I would love to see Mozilla moving to Codeberg.org (though I’d ask if they’re okay with it first) or something like that. Using GitHub is okay-ish? Personally, I frown upon it, but again I agree – it’s not the most important issue right now.

39. filcuk ◴[] No.43972649{3}[source]
God help the poor sod having to sort through that pile of submitted garbage.
40. lupusreal ◴[] No.43972847{3}[source]
I've been on the front line of user bug reports for much of my career, so I definitely know what it's like. I also have very little sympathy for the complaints. Devs want to only take bug reports from other devs, and more so, only experienced devs, and more so, only devs specifically with experience with that specific project... That's great for the short term interests of the devs but not for the long term prospects of the project.

It's really not that hard to sort through user bug reports, find and categorize the ones that are actionable and respond with boilerplate requests for more information to the rest. It's not super enjoyable, it's work, but it's absolutely manageable and devs need to keep some perspective when they complain about it. I think maybe a mandatory part of every CS education should be an internship in messy and difficult manual labor so that devs have some real context about what it means for a job to be unpleasant.

replies(1): >>43982660 #
41. lupusreal ◴[] No.43972908{3}[source]
Many times I have encountered Firefox bugs that either haven't been reported, or which bugzilla's shit search makes too hard for me to find. Usually that's where I give up because it's a pain in the ass to enter reports in bugzilla, the whole process seems intended to scare off anybody not in the organization.
replies(1): >>43976313 #
42. extraduder_ire ◴[] No.43973248{6}[source]
When did they ask you for a phone number? Last github account I set up back at the end of February didn't ask for one and does the mandatory 2fa step using a code sent via email.

This might be a country-dependant thing.

replies(1): >>43973415 #
43. hedora ◴[] No.43973386{7}[source]
Thanks. I didn’t realize that. Migrating repos tonight.
44. hedora ◴[] No.43973415{7}[source]
They nagged me for a year for a phone number, threatening lockout. I finally gave in, so they almost immediately started nagging me to disable SMS 2FA because it is insecure.
45. hedora ◴[] No.43973427{5}[source]
GitHub has been under 3 nines for the last year for me.
46. birdman3131 ◴[] No.43973491{7}[source]
I have never noticed that and am rarely logged in.
replies(1): >>43973532 #
47. alabastervlog ◴[] No.43973532{8}[source]
Weird. Maybe it just hates my last two ISPs (Google Fiber, Frontier).

The usual way I notice I'm not logged in is by getting blocked after interacting with ~3 different parts of the site within a minute. If I search, click a single repo, and stay in that repo without using search, it seems to go OK, but if I interact with search and then a couple repos, or search again, temp-banned.

replies(1): >>44008945 #
48. dblohm7 ◴[] No.43973600{4}[source]
Former Mozilla employee here.

I've been gone for a few years now and have no insight into this decision, so take anything I say with a grain of salt. Having said that, I think that, for better or worse, GitHub is probably the best location simply because it provides the lowest barrier to entry for new contributors.

I know that's spicy enough to trigger dozens of keyboard warriors hitting the reply button, but every little thing that deviates from "the norm" (for better or for worse, GitHub is that) causes a drop-off in people willing to contribute. There are still people out there, for example, who refuse to create an account on bugzilla.mozilla.org (not that this move to GitHub changes that).

replies(1): >>43974776 #
49. fu-hn ◴[] No.43973618{7}[source]
They no longer allow sorting by number of stars in the search without being logged in either.
replies(1): >>43981076 #
50. dblohm7 ◴[] No.43973634[source]
I understand what you're saying, but still:

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

replies(1): >>43974805 #
51. burkaman ◴[] No.43974008{7}[source]
Just opened a private window to try this, I did one search and clicked on four results, then a second search and got a 429 error. That is wild. I guess it's an anti-scraper measure?
replies(1): >>43975175 #
52. ◴[] No.43974101{7}[source]
53. LtdJorge ◴[] No.43974450[source]
Will GeckoView and Mozilla Android Components be on GitHub too?
replies(2): >>43976219 #>>43977371 #
54. ErikBjare ◴[] No.43974488{3}[source]
99% of browser users shouldn't file bug reports. I'd rather wait for a high-quality report than drown in low-quality reports.
55. thayne ◴[] No.43974555[source]
Given that Phabricator has been discontinued, are there any plans to replace that with something else? Phorge perhaps?
replies(1): >>43976087 #
56. LadyCailin ◴[] No.43974590{8}[source]
A phone number given to a generally reputable company is hardly equivalent to giving a rando your social security number.

I mean, obviously you disagree with them being generally reputable, but you must realize that’s not a broad opinion, and they are certainly better at preventing data breaches than the average company that stores phone numbers.

Sincerely though, I hope you get your GDPR request sorted.

replies(1): >>43974812 #
57. nine_k ◴[] No.43974654{5}[source]
Question: could I offer a patch without having a GitHub account?

Definitely I can access the source code. The review tools are not on GitHub. But is it even possible to host my proposed changes elsewhere, not on GitHub? I suppose that the answer is negative, but surprises happen.

This is a relatively theoretical question, but it explores the "what bad Microsoft can do to you" avenue: it can close your GitHub account, likely seriously hampering your ability to contribute.

replies(1): >>43975365 #
58. fsflover ◴[] No.43974759{4}[source]
https://news.ycombinator.com/item?id=43971550
replies(1): >>43980023 #
59. fsflover ◴[] No.43974776{5}[source]
> There are still people out there, for example, who refuse to create an account on bugzilla.mozilla.org (not that this move to GitHub changes that).

https://news.ycombinator.com/item?id=43971550

60. nirvdrum ◴[] No.43974805{3}[source]
I wish GitHub had a way to interface with an external issue tracker. I know it's not entirely on them, but it'd be great if there were some sort of standard for this. I'd love to embed an issue tracker from elsewhere.
61. fsflover ◴[] No.43974812{9}[source]
> generally reputable company

Are you talking about Microsoft here? https://en.wikipedia.org/wiki/Microsoft#Controversies

replies(1): >>43974899 #
62. LadyCailin ◴[] No.43974899{10}[source]
Hence the qualifier “generally”. I’m not saying they’re above reproach, but I am saying that companies that care far less about data security already have my phone number, such as most/all of my utilities - including my phone company. And those aren’t realistically optional.
replies(2): >>43975571 #>>43977855 #
63. fencepost ◴[] No.43975175{8}[source]
Given the occasional articles that crop up showing the sheer volume of badly-behaved (presumably) AI scraper bots this makes all kinds of sense.

I can't find it now, but sometime in the past week or so I saw something that (IIRC) related to the BBC (?) blocking a ton of badly-behaved obvious scraper traffic that was using Meta (?) user-agents but wasn't coming from the ASNs that Meta uses. The graphs looked like this ended up reducing their sustained traffic load by about 80%.

Items where I'm doubting my recall (since I didn't find anything relevant doing some quick searches) are marked with (?)

64. steveklabnik ◴[] No.43975365{6}[source]
This is my understanding from reading the docs just now:

You submit patches to Phabricator, not to GitHub.

https://firefox-source-docs.mozilla.org/contributing/contrib...

> To submit a patch for review, we use a tool called moz-phab.

That does mean you need an account on Phabricator, but not on GitHub https://moz-conduit.readthedocs.io/en/latest/phabricator-use...

65. fsflover ◴[] No.43975571{11}[source]
> companies that care far less about data security already have my phone number ... including my phone company.

Far less than these?

https://news.ycombinator.com/item?id=40592789

https://news.ycombinator.com/item?id=12305598

https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Privacy...

This is unlikely.

replies(1): >>43977794 #
66. Operyl ◴[] No.43976087[source]
Both forks coexist and pull fixes from each other.
67. rstat1 ◴[] No.43976219[source]
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.

68. matkoniecz ◴[] No.43976313{4}[source]
there are definitely not yet reported bugs!

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

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

69. PaulDavisThe1st ◴[] No.43976364[source]
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.
70. esseph ◴[] No.43976791{3}[source]
HAH!
71. GabrielTFS ◴[] No.43977341{8}[source]
This seems like a poor argument. I don't like much either having the obligation to give GitHub my phone number, but it's not the same thing as a social security number, now is it ? Would you argue otherwise ?
replies(1): >>43977825 #
72. ◴[] No.43977371[source]
73. xenator ◴[] No.43977390{3}[source]
If availability is on option then why Github? It doesn't support ipv6 and just cur people from part of the world. It denies access from Iran and other countries that US govs "doesn't like". I understand when small projects are hosted on Github, but Firefox should be much bigger to fit on Github.
74. Dylan16807 ◴[] No.43977794{12}[source]
The bar is a lot lower than you think.
replies(1): >>43994702 #
75. baobun ◴[] No.43977825{9}[source]
Not US but phone number is arguably worse: You can't legally get one without tying it to govt ID anymore and tends to be tied to your current physical location.
replies(1): >>43987133 #
76. baobun ◴[] No.43977855{11}[source]
> but I am saying that companies that care far less about data security already have my phone number

Not mine and it sucks that this means I'm not welcome as FireFox contributor anymore unless I move countries just to register a monthly contract for a dedicated GitHub-accepted SIM card.

Once you trigger phone-number verification requirement your account is globally shadowbanned and support blocked pending SMS code verification. Aside from the privacy issue it's completely blocking people in the several countries (beyond the ones offially totally banned due to sanctions) to which GitHub won't even try to SMS/call.

Remember that registering a second account would be violating GitHub ToS.

replies(1): >>43987168 #
77. yndoendo ◴[] No.43980023{5}[source]
Mozilla has a lot more weight to throw around in incidents like this. Personally, I would never use Github. Microsoft keeps spiraling down the Enshitification drain.
78. glandium ◴[] No.43980513{6}[source]
You don't need a Github account to `git clone https://github.com/some/repo`
79. guappa ◴[] No.43981076{8}[source]
Stars can be bought, they aren't very reliable.
80. marcusramberg ◴[] No.43981144{5}[source]
I use GitHub for work, and it very frequently has outages. Not sure codeberg could be much worse tbh.
81. dspillett ◴[] No.43982660{4}[source]
> Devs want to only take bug reports from other devs, and more so, only experienced devs, and more so, only devs specifically with experience with that specific project...

Nope, at least not this dev.

I want to take bug reports from people who can actually report something useful (not “something somewhere aint working” or “is the system OK?”), use their brain just slightly when making the report (if you got an error, it perhaps makes sense to include that message in the report, especially when you get a screen that explicitly states “please include this information in any bug reports”), and can read and pay attention to your responses when you request more information (actually answering the questions, all of them, not just one of them that they think is most relevant, or something different that they think is relevant instead) and who don't get offended when they respond to a further request for the required information with “this is getting urgent now!” and I reply with “then it is getting urgent that you send the information that I've requested twice now”¹.

> Devs want to only take bug reports from other devs

Furthermore, I've had terrible reports from devs and other technical types. Some non-technical end users have in the past sent me far better reports than some devs seem capable of. This is particularly galling because they then complain about how bad end user reports/requests are… I don't mind it from a fresh junior, but anyone else in our line of work should know better.

> It's really not that hard to sort through user bug reports…

It also isn't hard for people to properly describe the issue they are experiencing. It would be nice to be met half way. :)

TBH a lot of my irritation comes from the industry my employer operates in. While I try to stay away from the money and contracts side even more than I try to stay away from being end-user facing, I know that they often request our fees be itemised, and then expect a reduction for the bit marked “first line support” or similar because “our people will triage problems from our users and collate the details”, but their idea of “triage & collate” is just forwarding every email they get to support@ourdomain.tld… This narrow world view might not be relevant to a large public project.

> internship in messy and difficult manual labor so that devs have some real context about what it means for a job to be unpleasant

Younger me worked retail in a theme park, and did warehouse work, and had friends who managed a farm³, I have a fair idea what a hard day of work is.

----

[1] Actually, this no longer happens. My employer is bright enough that there is a buffer between me and client-facing tasks, except occasionally when something properly technical² needs discussing between their tech people and ours.

[2] Though “properly technical” can sometimes mean explaining how key-based auth works for SSH, to someone with a grandiose job title like “Infrastructure Architect”!

[3] Now that is a multi-faceted set of physical and mental complications which make my life, and those of people sending bad bug reports and change requests, look particularly easy.

82. Cthulhu_ ◴[] No.43983534{3}[source]
Only for as long as GH is only used for version control; if they also start to rely on PRs or issues or whatnot, the enmeshment will become worse.
83. jgrowl ◴[] No.43986761{7}[source]
I was pretty flabbergasted when I realized that if not logged in, I could no longer search a repository for code references.

You're really going to make me clone a project locally to do a search. I just end up using google to search github. It's so stupid.

replies(1): >>44006409 #
84. IIsi50MHz ◴[] No.43987133{10}[source]
And is commonly used for authentication codes, and like Social Security Number, it is PII that should be default-deny.

Github seems to have no legit need for a user's phone number. Since there's not even a way to tell them to go pound sand, I'd say opting out of disclosing sensitive information they don't need by not signing in/up and equating their unreasonable demand with a ban is respectable.

85. IIsi50MHz ◴[] No.43987168{12}[source]
It looks like patches still get submitted to another system, and github is only used indirectly for version control.
86. fsflover ◴[] No.43994702{13}[source]
Tell me more. Meanwhile: https://news.ycombinator.com/item?id=43993076
87. OrangeMusic ◴[] No.44006409{8}[source]
Or, log in?
replies(1): >>44013241 #
88. aabbcc1241 ◴[] No.44008945{9}[source]
I made a search index for github repo [1] because it takes quite some time for github to load the repositories page (which is the page to allow searching),

And sometimes even using the exact repo name in Google search, I cannot see the corresponding (non-popular) repo.

[1] https://res-index.hkit.cc

89. deathlight ◴[] No.44013241{9}[source]
There is a huge irony in me logging in to this website to posit the question to you: why?