Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla Firefox – Official GitHub repo

github.com

Post reply on HN
Print view View original

191–200 of 481 posts

Re: Mozilla Firefox – Official GitHub repo

#191

Post by int_19h »

berkes wrote: post #176
fhd2 wrote: post #170

Earlier quoted context omitted.

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.

You just showed the poster-child of gatekeeping that is harming Open Source. Every contributor is valuable, it's in the name, the definition of "contribute". Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse. Now, to be clear, while I do think GitHub is currently the "solution" to…

This is just blatantly wrong on so many levels.

Proposed contributions can in fact have negative value, if the contributor implements some feature or bug fix in a way that makes it more difficult to maintain in the long term or introduces bugs in other code.

And even if such contribution is ultimately rejected, someone knowledgeable has to spend time and effort reviewing such code first - time and effort that could have been spend on another, more useful PR.

Re: Mozilla Firefox – Official GitHub repo

#192

Post by selectnull »

neilv wrote: post #143
selectnull wrote: post #103

Earlier quoted context omitted.

Mozilla is US organization, why would they care to?

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 Microsof…

Given the Mozilla direction lately, the last thing they want is good data protection laws.

Re: Mozilla Firefox – Official GitHub repo

#193

Post by notpushkin »

bayindirh wrote: post #189
iamcreasy wrote: post #168

Earlier quoted context omitted.

Thanks for the added context. If I may - what were the significant scale challenges for self hosted solution?

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 hou…

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)

Re: Mozilla Firefox – Official GitHub repo

#194

Post by starspangled »

bandrami wrote: post #12

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.

Really? You rm -rf your working trees each evening before you finish, and git clone them from github in the morning? :)

I store my code in a completely distributed fashion, often in several places on different local devices (laptop, build server, backup, etc) not to mention on remote systems. I use github and gitlab for backup and distribution purposes, as well as alternative ways people can share code with me (other than sending patch emails), and other people use git to get and collaborate on my work.

distributed version control system doesn't mean distributed storage magically happens. You still need to store your code on storage you trust at some level. The distributed in DVCS means that collaboration and change management is distributed. All version control operations can be performed on your own copy of a tree with no other involvement. Person A can collaborate with person B, then person B can collaborate with person C without person A being in the loop, etc.

Re: Mozilla Firefox – Official GitHub repo

#195

Post by jgraham »

iamcreasy wrote: post #168
jgraham wrote: post #158

(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 s…

Thanks for the added context. If I may - what were the significant scale challenges for self hosted solution?

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

Re: Mozilla Firefox – Official GitHub repo

#196

Post by arp242 »

bayindirh wrote: post #189
iamcreasy wrote: post #168

Earlier quoted context omitted.

Thanks for the added context. If I may - what were the significant scale challenges for self hosted solution?

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 hou…

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

Re: Mozilla Firefox – Official GitHub repo

#197

Post by bayindirh »

notpushkin wrote: post #193
bayindirh wrote: post #189

Earlier quoted context omitted.

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 hou…

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)

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.

Re: Mozilla Firefox – Official GitHub repo

#198

Post by flohofwoe »

vishnugupta wrote: post #128
flohofwoe wrote: post #79

Earlier quoted context omitted.

> They learn a set of narrow workflows and never explore beyond. And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem. I don't need to know how a fi…

svn was a nightmare when it came to handling conflicts. So at least for me, humming in the background wasn’t the term used for it at work.

This was only for true before svn 1.5 (before it had 'merge tracking'). Also, branching and merging by far wasn't as essential in svn as it is in a decentralized version control system like git. In a centralized version control system it works perfectly well to do all development in the main branch, and only branch off dead-end 'release branches' which are never merged back.

Tbh, I really wonder where the bad reputation of svn is coming from. Git does some things better, especially for 'programmer-centric teams'. But it also does many things worse, especially in projects where the majority of data is large binary files (like in game development) - and it's not like git is any good either when it comes to merging binary data.

Re: Mozilla Firefox – Official GitHub repo

#199

Post by bayindirh »

arp242 wrote: post #196
bayindirh wrote: post #189

Earlier quoted context omitted.

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 hou…

> 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 req…

It was a guess and I never claimed it was 100% correct, and I'm happy to stand corrected. No hard feelings there.

Re: Mozilla Firefox – Official GitHub repo

#200

Post by jgraham »

bayindirh wrote: post #189
iamcreasy wrote: post #168

Earlier quoted context omitted.

Thanks for the added context. If I may - what were the significant scale challenges for self hosted solution?

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 hou…

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.

Post reply on HN