Live data from Hacker News

Mozilla Firefox – Official GitHub repo

github.com

221–230 of 481 posts

Re: Mozilla Firefox – Official GitHub repo

#221
post #26

Earlier quoted context omitted.

I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back. Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by dist…

This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.

The annoying thing about Fossil is that it doesn't let you squash commits, not even in your private branches - they have some kind of philosophical point about that.

If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.

Re: Mozilla Firefox – Official GitHub repo

#222

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

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.

Re: Mozilla Firefox – Official GitHub repo

#223

Earlier quoted context omitted.

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

why github and not codeberg? badwidth? $$$ from microsoft? (traffic, free training for copilot, ..)

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.

Re: Mozilla Firefox – Official GitHub repo

#224

Earlier quoted context omitted.

> Everything surrounding code: issues, CICD, etc, is obviously another story That's what Github is though, it's not about the code itself it's about all your project management being on Github, and once you move it, moving out isn't realistic.

And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. I think we should be grateful that the core underlying protocol for the most important data has the distributed properties we want. It's a lot more than we can say vs. lots of other platforms out there.

By storing issues etc in the repo itself. A git repo is just a generic object graph, after all, and objects don't necessarily describe files.

There are several such solutions already. The problem is that neither of them is popular enough to become a de facto standard. And, of course, centralized git providers like GitHub have a vested interest in keeping in this way, so they are unlikely to support any such solution even if it does become popular enough.

Re: Mozilla Firefox – Official GitHub repo

#225
post #170

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

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.

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

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

Re: Mozilla Firefox – Official GitHub repo

#226
post #176
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…

In spirit, I agree.

In practice, if you get dozens of PRs from people who clearly did it to bolster up their CV, because their professor asked them or something like that, it just takes a toll. It's more effort than writing the same code yourself. Of course I love to mentor people, if I have the capacity. But a good chunk of the GitHub contributions I've worked on were pretty careless, not even tested, that kind of thing. I haven't done the maintainer job in a while, I'm pretty terrified by the idea of what effect the advent of vibe coding had on PR quality.

I feel pretty smug the way I'm talking about "PR quality", but if the volume of PRs that take a lot of effort to review and merge is high enough, it can be pretty daunting. From a maintainer perspective, the best thing to have are thoughtful people that genuinely use and like the software and want to make it better with a few contributions. That is unfortunately, in my experience, not the most common case, especially on GitHub.

Re: Mozilla Firefox – Official GitHub repo

#227
post #63

Earlier quoted context omitted.

Plenty of people use Codeberg and Gitlab. And it's still distributed - I don't need to lock files and ask coworkers if I can work on them. Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email etc.)

In Codeberg, how does one even search for files containing a given string? Probably the #1 thing I do on GitHub is searching for files in a project containing a given string.

I'm not being sarcastic but how do you do it on github?;) it basically never works

Not only results are incomplete but it seems once they went into training LLMs on all code they host they made sure no one else can do the same easily and so now everything is madly rate limited.

Every time I just clone and grep.

Re: Mozilla Firefox – Official GitHub repo

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

"gatekeeping good" no.

They are everywhere. It's like a plague.

Re: Mozilla Firefox – Official GitHub repo

#229
post #170

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

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.

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