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

201–210 of 481 posts

Re: Mozilla Firefox – Official GitHub repo

#201

Post by arp242 »

struanr wrote: post #190
arp242 wrote: post #184

Earlier quoted context omitted.

I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process. Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not. I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figurin…

Although I have certainly created pull requests before that have been ignored so not sure GitHub solves this problem.

GitHub PRs don't solve anything about that, but I wouldn't have to spend (waste) time figuring out the contribution process. At least I learned a few things writing the patches. I learned nothing of value dealing with git email or Phabricator. It's just work of the boring and tedious kind.

Re: Mozilla Firefox – Official GitHub repo

#202

Post by baq »

torben-friis wrote: post #61
mhh__ wrote: post #53

Earlier quoted context omitted.

Git should have issue support or something like it as a convention but pull requests are an abomination that we are stuck with. No thank you.

Can you expand on that? I’m probably younger but I can’t imagine a more comfortable way to review code.

It’s only good if you haven’t tried anything else. Check out gerrit, but there are many more tools and workflows.

Note we’re talking about the GitHub UI mostly. Pulling and merging a remote branch is a basic git operation, almost a primitive.

Re: Mozilla Firefox – Official GitHub repo

#203

Post by Philpax »

fhd2 wrote: post #170
floriangosse wrote: post #83

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.

I can say that I've chosen not to bother when submitting a fix requires me to stray away from GitHub, and doubly so when it doesn't use a PR/MR workflow. There are only so many hours in the day, and I don't have the patience to deal with unconventional workflows when there are other things I could be doing with my time.

For projects that I'd be interested in being a long-term contributor to, this is obviously different, but you don't become a long-term contributor without first dealing with the short-term, and if you make that experience a pain, I'm unlikely to stick around.

A big part of this is the friction in signing up; I hope federated forges become more of a thing, and I can carry my identity around and start using alternate forges without having to store yet another password in my password manager.

Re: Mozilla Firefox – Official GitHub repo

#204

Post by monegator »

jgraham wrote: post #195
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?

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

Re: Mozilla Firefox – Official GitHub repo

#206

Post by Tepix »

danpalmer wrote: post #10
reddalo wrote: post #6

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/ [2] https://codeberg.org/

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.

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.

Re: Mozilla Firefox – Official GitHub repo

#207

Post by nicman23 »

fhd2 wrote: post #170
floriangosse wrote: post #83

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.

"gatekeeping good"

no.

Re: Mozilla Firefox – Official GitHub repo

#208

Post by nicman23 »

int_19h wrote: post #191
berkes wrote: post #176

Earlier quoted context omitted.

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

lol go closed then

Re: Mozilla Firefox – Official GitHub repo

#210

Post by elric »

arp242 wrote: post #184
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.

I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process. Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not. I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figurin…

In all likelihood, if the patch had been a pull request, the pull request would have been ignored as well. Much like the thousands of pull requests that are often ignored by various larger open source projects. Ain't nobody got time to triage drive-by pull requests from unknown contributors, especially on large projects.

There's no easy solution. Much like the recent curl security kerfuffle, the signal:noise ratio is important and hard to maintain.

Post reply on HN