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

181–190 of 481 posts

Re: Mozilla Firefox – Official GitHub repo

#181

Post by flohofwoe »

guappa wrote: post #156
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…

Have you ever actually used svn?

Yes for about 18 years(?) in the context of game development (I don't exactly remember when we had switched from cvs to svn, but it must have been around 2003..2005) in teams up to about 100 people, working copy sizes up to about 150 GB (with most of the data being binary game asset files), and everybody working on trunk (we only used branches for releases which were branched off trunk but never merged back, only cherry-picking bugfixes from the main into release branches as needed).

We used TortoiseSVN as UI which worked well both for devs and non-devs.

With this sort of setup, git would break down completely if it weren't for awkward hacks like git-lfs (which comes with its own share of problems).

Re: Mozilla Firefox – Official GitHub repo

#182

Post by lpln3452 »

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.

Contribution isn’t driven by a desire for rewards, but by goodwill. Friction only gets in the way. If the friction is worth it, fine - but what exactly is being lost by moving the repository to GitHub?

Re: Mozilla Firefox – Official GitHub repo

#183

Post by rendaw »

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.

How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?

Re: Mozilla Firefox – Official GitHub repo

#184

Post by arp242 »

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 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 figuring out the contribution process has been a waste. Time I could have spent on more/other patches.

So yeah, there's that.

It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.

(aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)

Re: Mozilla Firefox – Official GitHub repo

#185

Post by berkes »

sneak wrote: post #177
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…

Not all PRs are created equal.

And that is good.

Diversity, here too, is of crucial importance. It's why some Open Source software has sublime documentation and impeccible translations, while the other is technically perfect but undecipherable. It's why some Open Source software has cute logos or appeals to professionals, while the other remains this hobby-project that no-one ever takes serious despite its' technical brilliance.

Re: Mozilla Firefox – Official GitHub repo

#186

Post by swiftcoder »

dgoldstein0 wrote: post #80
swiftcoder wrote: post #15

Earlier quoted context omitted.

Interesting that their issues are blamed on "dual SCM", not on Mercurial itself. I guess just the weight of contributors expecting Git as the default is sinking the big Mercurial projects these days.

Isn't mercurial abandonware? Or maybe I'm just remembering that gitlab dropped support. If it's not dead yet seems to be getting there

It’s still used by Meta, at any rate (albeit a very scaled version thereof). Meta picked it for their monorepo when Linus wasn’t willing to play ball on extending Git for their use case.

Re: Mozilla Firefox – Official GitHub repo

#187

Post by arp242 »

swiftcoder wrote: post #186
dgoldstein0 wrote: post #80

Earlier quoted context omitted.

Isn't mercurial abandonware? Or maybe I'm just remembering that gitlab dropped support. If it's not dead yet seems to be getting there

It’s still used by Meta, at any rate (albeit a very scaled version thereof). Meta picked it for their monorepo when Linus wasn’t willing to play ball on extending Git for their use case.

Is it still used there? I know they did in the past, but reading up a bit on the background on all of this I found https://github.com/facebook/sapling, and it seems that's what they're using now?

Re: Mozilla Firefox – Official GitHub repo

#188

Post by Tainnor »

jamienicol wrote: post #119
spookie wrote: post #71

Earlier quoted context omitted.

To be fair, most of the its difficulty is realized when you're stuck with a teammate rewriting history. Who, much like anyone anyone doing the same, hasn't bothered reading a book explaining things.

That problem is solved by preventing forced pushes. Rewriting history locally is encouraged.

Prevent forced pushes on protected branches (develop, main, hotfix etc.). I don't care if somebody force pushes their private feature branch.

Re: Mozilla Firefox – Official GitHub repo

#189

Post by bayindirh »

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?

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.

Re: Mozilla Firefox – Official GitHub repo

#190

Post by struanr »

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…

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