(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.
Thanks for the context. IMHO I don't think Mozilla should have decided to move to a closed-source platform owned by Microsoft.
fguerraz 11 hours ago [-]
Thanks to the decentralised nature of git, this should matter only moderately.
JeremyNT 10 hours ago [-]
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.
Given that Phabricator has been discontinued, are there any plans to replace that with something else? Phorge perhaps?
Operyl 5 hours ago [-]
Both forks coexist and pull fixes from each other.
iamcreasy 15 hours ago [-]
Thanks for the added context.
If I may - what were the significant scale challenges for self hosted solution?
jgraham 14 hours ago [-]
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).
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.
monegator 14 hours ago [-]
why github and not codeberg?
badwidth? $$$ from microsoft? (traffic, free training for copilot, ..)
GuB-42 13 hours ago [-]
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.
nine_k 7 hours ago [-]
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.
steveklabnik 6 hours ago [-]
This is my understanding from reading the docs just now:
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.
alabastervlog 11 hours ago [-]
> 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.
burkaman 8 hours ago [-]
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?
fencepost 6 hours ago [-]
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 (?)
hedora 8 hours ago [-]
Thanks. I didn’t realize that. Migrating repos tonight.
fu-hn 8 hours ago [-]
They no longer allow sorting by number of stars in the search without being logged in either.
birdman3131 8 hours ago [-]
I have never noticed that and am rarely logged in.
alabastervlog 8 hours ago [-]
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.
baobun 11 hours ago [-]
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.
extraduder_ire 9 hours ago [-]
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.
hedora 8 hours ago [-]
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.
LadyCailin 11 hours ago [-]
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.
7 hours ago [-]
immibis 11 hours ago [-]
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.
GabrielTFS 2 hours ago [-]
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 ?
baobun 2 hours ago [-]
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.
LadyCailin 7 hours ago [-]
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.
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.
baobun 2 hours ago [-]
> 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.
fsflover 5 hours ago [-]
> companies that care far less about data security already have my phone number ... including my phone company.
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).
fsflover 6 hours ago [-]
> 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).
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
Miaourt 13 hours ago [-]
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
prepend 13 hours ago [-]
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.
executesorder66 12 hours ago [-]
Yeah, it's not like they care about improving the state of the open source ecosystem anyway.
hedora 8 hours ago [-]
GitHub has been under 3 nines for the last year for me.
Slartie 14 hours ago [-]
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.
jorvi 13 hours ago [-]
Why did you omit (self-hosted) gitlab..?
dspillett 12 hours ago [-]
[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.
freeopinion 10 hours ago [-]
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.
bayindirh 14 hours ago [-]
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.
jgraham 14 hours ago [-]
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.
arp242 14 hours ago [-]
> 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?
bayindirh 14 hours ago [-]
It was a guess and I never claimed it was 100% correct, and I'm happy to stand corrected. No hard feelings there.
tempaccount420 13 hours ago [-]
"I guess..." != "I'm guessing..."
bayindirh 13 hours ago [-]
That's new to me. Can you expand on that a little?
notpushkin 14 hours ago [-]
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)
saghm 13 hours ago [-]
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.
notpushkin 10 hours ago [-]
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.
bayindirh 14 hours ago [-]
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.
TheDong 12 hours ago [-]
> 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?
bayindirh 11 hours ago [-]
It was an, apparently very wrong, educated guess. Nothing more.
PaulDavisThe1st 4 hours ago [-]
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.
LtdJorge 7 hours ago [-]
Will GeckoView and Mozilla Android Components be on GitHub too?
2 hours ago [-]
rstat1 4 hours ago [-]
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.
lupusreal 12 hours ago [-]
> 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..)
jgraham 12 hours ago [-]
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.
dspillett 12 hours ago [-]
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? :-)
lupusreal 9 hours ago [-]
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.
dblohm7 8 hours ago [-]
I understand what you're saying, but still:
GitHub issues is terrible compared to Mozilla's Bugzilla instance. It's not even close.
nirvdrum 6 hours ago [-]
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.
matkoniecz 12 hours ago [-]
I suspect that Firefox is not bottlenecked on number of bug reports they got.
lupusreal 9 hours ago [-]
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.
matkoniecz 4 hours ago [-]
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
AlienRobot 11 hours ago [-]
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.
ErikBjare 7 hours ago [-]
99% of browser users shouldn't file bug reports. I'd rather wait for a high-quality report than drown in low-quality reports.
filcuk 10 hours ago [-]
God help the poor sod having to sort through that pile of submitted garbage.
floriangosse 16 hours ago [-]
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 dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.
fhd2 15 hours ago [-]
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.
arp242 14 hours ago [-]
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)
elric 14 hours ago [-]
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.
amanda99 10 hours ago [-]
I think the OP's point here was that if it's a PR and it's ignored: you spent a bunch of time writing a PR (which may or may not have been valuable to you, e.g. if you maintain a fork now). On the other hand, if it was an esoteric contribution process, you spent a lot of time figuring out how to get the patch in there, but that obviously has 0 value outside contributing within that particular open source project.
struanr 14 hours ago [-]
Although I have certainly created pull requests before that have been ignored so not sure GitHub solves this problem.
arp242 14 hours ago [-]
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.
TheDong 12 hours ago [-]
Dealing with github is the boring and tedious thing, you have to run huge amount of proprietary javascript, keep up with their weird UX changes, start X11 to open a browser to render their html, overclock your CPU for a large PR review conversation to scroll without locking up your computer for minutes, constantly click "load more" since their webpage keeps hiding comments (while still lagging massively)...
Email is simple. It's just text, there's no weird javascript or html or lag. I don't have to open X11. I can just open mutt and read or write. I can type "git send-email". It's all open source, so I can read the code to understand it, and write scripting around it. It runs on any computer with ease. Even on a slow connection, it's quite speedy.
I totally agree with you about Phabricator though.
einsteinx2 3 hours ago [-]
So you can compile and test your changes to Firefox without starting X11 or “overclocking your CPU” but you can’t use a simple website?
Osiris 5 hours ago [-]
Use the GitHub CLI.
You can do nearly everything the website does entirely in the terminal.
twic 9 hours ago [-]
It's not true that you need to start X11. GitHub's UI renders pretty well under Wayland.
arp242 11 hours ago [-]
"Boo hoo I need to start X11"? Seriously?
I have some unconventional workflows. And I try not to bother anyone else with it, especially in a volunteer driven open source context. It would be selfish to do otherwise.
To be honest based on what you've written here, keeping you out of my projects sounds like a good thing. What a bunch of piss and vinegar over how other people are choosing to work in a way that works for them.
elteto 10 hours ago [-]
Starting X takes forever on his PDP11. Only real way to run Unix.
elric 14 hours ago [-]
Many projects have rules about what kinds of pull requests they accept. You would still have had to familiarise yourself with those rules, as well as the usual things like coding style, testing policies, etc.
andybak 11 hours ago [-]
Surely the claim being made is that the overall effort was increased in this case. That makes sense to me. I guess you can debate "but by how much?" but it seems fairly clear that there is more friction than there would have been via Github PRs
berkes 15 hours ago [-]
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 lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?
fhd2 13 hours ago [-]
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.
arp242 12 hours ago [-]
In my experience low-quality PRs aren't that common, but I do agree dealing with them is annoying. You can't just tell people to go away because they did spend their spare time on it. On the other hand it's also garbage. Sometimes it's garbage by people who really ought to know better. IMHO low-quality issues are the bigger problem by the way, a problem that existed well before GitHub.
But I just don't see how GitHub or a PR-style workflow relates. Like I said in my own reply: I think it's just because you'll receive less contributions overall. That's a completely fair and reasonable trade-off to make, as long as you realise that is the trade-off you're making.
int_19h 14 hours ago [-]
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.
dgb23 12 hours ago [-]
It's not wrong, it's just based on the assumption that the projects wants contributors.
Quite obviously, any incidental friction makes this ever so slightly harder or less likely. Good contributions don't necessarily or only come from people who are already determined from the get go. Many might just want to dabble at first, or they are just casually browsing and see something that catches their attention.
Every projects needs some form of gatekeeping at some level. But it's unclear to me whether the solution is to avoid platforms with high visibility and tools that are very common and familiar. You probably need a more sophisticated and granular filter than that.
skydhash 9 hours ago [-]
> Many might just want to dabble at first, or they are just casually browsing and see something that catches their attention.
You can easily craft an email for that. No need to create a full PR.
LegionMammal978 8 hours ago [-]
"Crafting an email" in the format required by many email-based projects is hardly easy for the average user, who's most likely using a webmail service that does not have much control over line wrapping and the like. Accepting patches in attachments (instead of the email body) helps with this, but naive users can still easily get caught by using HTML email, which many project maintainers love to performatively turn up their noses at.
lpln3452 13 hours ago [-]
This isn't a platform issue — it's a problem with the PR system, and arguably with open source itself. If you're unwilling to spend time on anything beyond writing code, maybe keep the project closed-source.
majewsky 13 hours ago [-]
Or, more obviously, make it open-source, and make a big fat note in the README of "I will not accept PRs, this repo is just for your consumption, fork it if you want to change it".
int_19h 12 hours ago [-]
It's not a binary. Many projects do want PRs, but it doesn't mean they have to accept any random PR, or fawn over every contributor who creates an obviously low-effort one. It's perfectly fine to "gatekeep" on quality matters, and that does mean acknowledging the fact that not all contributors are equally valuable.
matheusmoreira 8 hours ago [-]
> fawn over every contributor who creates an obviously low-effort one
It's that sense of superiority that pisses me off.
Many maintainers condescendingly reply "contributions welcome" in response to user complaints. People like that had better accept whatever they get. They could have easily done it themselves in all their "high quality" ways. They could have said "I don't have time for this" or even "I don't want to work on this". No, they went and challenged people to contribute instead. Then when they get what they wanted they suddenly decide they don't want it anymore? Bullshit.
You're making the assumption that these are "high quality" projects, that someone poured their very soul into every single line of code in the repository. Chances are it's just someone else's own low effort implementation. Maybe someone else's hobby project. Maybe it's some legacy stuff that's too useful to delete but too complex to fully rewrite. When you dive in, you discover that "doing it properly" very well means putting way too much effort into paying off the technical debts of others. So who's signing up to do that for ungrateful maintainers for free? Who wants to risk doing all that work only to end up ignored and rejected? Lol.
Just slap things together until they work. As long as your problem's fixed, it's fine. It's not your baby you're taking care of. They should be grateful you even sent the patches in. If they don't like it, just keep your commits and rebase, maybe make a custom package that overrides the official one from the Linux distribution. No need to worry about it, after all your version's fixed and theirs isn't. Best part is this tends to get these maintainers to wake up and "properly" implement things on their side... Which is exactly what users wanted in the first place! Wow!
majewsky 8 hours ago [-]
> People like that had better accept whatever they get.
FOSS maintainers are not a unified mind. The people who go "contributions welcome" and "#hacktoberfest" are somewhere near one end of the spectrum, and the folks dealing with low-effort contributions are somewhere near the other end of the spectrum.
matheusmoreira 8 hours ago [-]
Of course not. That's why I singled out a very specific kind of maintainer: the type who thinks himself superior to users even when they engage at their level. Guys so good they can't be bothered to do it themselves but complain when others do it.
Good maintainers may be firm but they are always nice and grateful, and they treat people as their equals. They don't beg others for their time and effort. If they do, they don't gratuitously shit on people when they get the results. They work with contributors in order to get their work reviewed, revised and merged. They might even just merge it as-is, it can always be refactored afterwards.
That's hard to do and that's why doing it makes them good maintainers. Telling people their "contributions are welcome" only to not welcome their contributions when they do come is the real "low effort".
int_19h 3 hours ago [-]
> Just slap things together until they work. As long as your problem's fixed, it's fine. It's not your baby you're taking care of. They should be grateful you even sent the patches in.
Thank you for a clear and concise illustration of why some contributions are really not welcome.
Just about the only thing I will agree with you on is that projects should indeed make it clear what the bar for the proper contribution is. This doesn't mean never saying "contributions are welcome", if they are indeed welcome - it's still the expectation for whoever is contributing to do the bare minimum to locate those requirements (e.g. by actually, you know, reading CONTRIBUTING.md in the root of the repo before opening a PR - which many people do not.)
matkoniecz 4 hours ago [-]
> People like that had better accept whatever they get.
no, I am not obligated to merge badly written PRs introducing bugs just because I had no time to implement the feature myself
14 hours ago [-]
nicman23 14 hours ago [-]
lol go closed then
sneak 15 hours ago [-]
Not all PRs are created equal.
myfonj 14 hours ago [-]
Also don't forget that not all contributions are done through PRs or are actual code changes. There are folks that do tests, make MREs, organise issue reports, participate in forums … they all are also contributing: their time and efforts.
berkes 14 hours ago [-]
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.
matkoniecz 12 hours ago [-]
> Every contributor is valuable, it's in the name, the definition of "contribute".
No. I definitely seen people who created multitude of misleading bug reports, flood of stupid feature requests. I personally did a bit of both.
There are people who do both repetitively, fill issue reports without filling requested fields. Or open issue again when their previous report was closed.
I got once bug report where someone was ranting that app is breaking data. Turned out (after wasting my time on investigating it) that user broke data on their own with different software, through its misuse.
There were PRs adding backdoors. This is not a valuable contribution.
There were PRs done to foment useless harmful political mess.
Some people pretend to be multiple people and argue with themselves in pull requests or issues (using multiple accounts or in more bizarre cases using one). Or try to be listed multiple times as contributor.
Some people try to sneak in some intentionally harmful content one way or another.
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.
Handler9246 12 hours ago [-]
Sad we're at a stage where people don't contribute to free software projects because the service it's hosted on isn't the proprietary, corporate giant.
"Friction in signing up" being a big part for you is also weird, considering basically all free software GitHub alternatives (Gitea, GitLab, Forgejo) support SSO via GitHub.
encom 9 hours ago [-]
Requiring a Microsoft account, and handing over my phone number is extreme friction in my book.
lpln3452 14 hours ago [-]
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?
baobun 10 hours ago [-]
> but what exactly is being lost by moving the repository to GitHub?
Contributors who can't use GitHub because either 1) they are fresh and can't activate a new account 2) their old grandfathered account is no longer usable or 3) their old account id doxxed and they can no longer safely contribute under the old identity.
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 countries to which GitHub won't even try to SMS/call.
Remember that registering a second account would be violating GitHub ToS.
stevekemp 13 hours ago [-]
The number of emails I get "Your website is vulnerable to clickjacking attacks, PS. how much bounty have I earned?" suggests that there are many for whom a desire for literal rewards is their sole driver.
Not to mention the AI-generated security "issues" that are reported against curl, for example, suggests there can indeed be negative value for reports, and contributions.
lpln3452 12 hours ago [-]
You're right. And that's not an issue with any particular platform, but with open source projects that accept issues and PR in general.
I don't think this is the place for a debate about the overall utility of open source.
Aachen 13 hours ago [-]
> what exactly is being lost by moving the repository to GitHub?
Alternatives to github
We lament Google's browser engine monopoly, but putting the vast majority of open source projects on github is just the expected course to take. I guess we'll repeat history once microsoft decides to set in the enshittification, maybe one day mobile OSes replace Windows and they're strapped for cash, who knows, but it's a centralised closed system owned by a corporation that absolutely adores FOSS
I don't mind any particular project (such as this one) being in Github and I can understand that Mozilla chooses the easy path, they've got bigger problems after all, but it's not like there are no concerns with everyone and everything moving to github
13 hours ago [-]
13 hours ago [-]
lpln3452 13 hours ago [-]
Did you ever use the alternatives before GitHub took off?
GitLab? It was awful. Slow, and paying for that kind of experience felt like a bad joke.
It's much better now but it was borderline unusable back in the day.
Or SourceForge, before Git was mainstream? Also terrible.
GitHub succeeded because it quickly established itself as a decent way to host Git - not because it was exceptional, but because the competition had abysmal UX.
Unlike other lock-in-prone services, moving a Git project is trivial. If GitHub loses its advantages due to enshittification, you just move. Case in point: Mozilla hopping on and off GitHub, as this article shows.
Philpax 13 hours ago [-]
I believe GitLab post-dates GitHub, but I otherwise agree with the sentiment.
12 hours ago [-]
12 hours ago [-]
lpln3452 12 hours ago [-]
You're right. But as far as I remember, neither GitHub nor GitLab were really mainstream at the time.
I think the real competition began around the same time.
matkoniecz 12 hours ago [-]
> Unlike other lock-in-prone services, moving a Git project is trivial.
not really
just moving issue tracker and discussions is highly annoying
trying to get your users to move is likely hard and you will lose many
still, may be easy in comparison
rendaw 14 hours ago [-]
How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?
fhd2 14 hours ago [-]
Not possible, but I have a comparison between projects on GitHub and projects not on GitHub (and generally more ceremony).
A lot more contributions on GH, but the majority of them ignored guidelines and/or had low code quality and attention to detail. Just my anecdotal experience of course.
pornel 13 hours ago [-]
The barriers may keep out low effort submissions*, but they also keep out contributors whose time is too valuable to waste on installing and configuring a bespoke setup based on some possibly outdated wiki.
* contributors need to start somewhere, so even broken PRs can lead to having a valuable contributor if you're able to guide them.
arichard123 13 hours ago [-]
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.
13 hours ago [-]
nicman23 14 hours ago [-]
"gatekeeping good"
no.
bigstrat2003 6 hours ago [-]
Declaring gatekeeping to be always and forever bad is an unhelpful, untrue thought-terminating cliche. A wide variety of situations can be described as "gatekeeping", and while some are nonsense some are very good to keep. It's bad if we say "you must be 6 feet tall to be a doctor", because that has nothing to do with being a good doctor. But requiring that doctors get a medical degree and pass certification requirements is also gatekeeping, and it would also be insane to do away with it. Any time you call gatekeeping bad for its own sake you are engaging in a gross oversimplification, and should stop.
7bit 13 hours ago [-]
They are everywhere. It's like a plague.
Aachen 13 hours ago [-]
Am I understanding you correctly that using github instead of a more obscure system where you might need to register a fresh account and find where the buttons are etc. raises the bar for contributions and so it's good to use github?
Somehow I think you're holding the difficulty scale backwards!
7bit 13 hours ago [-]
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.
bigstrat2003 6 hours ago [-]
> Being a good coder has absolutely no correlation to being good at using Mercurial.
No, but being a good coder is strongly anti-correlated with being unable or unwilling to figure out Mercurial.
madeofpalk 12 hours ago [-]
I absolutely gave up on trying to contribute a patch to Firefox because the combination of both gh and phabricator was too much for me.
I struggled to understand how the two interacted with each other, and I didn't know how to 'update my branch/pr' and I eventually just gave up.
lolinder 9 hours ago [-]
With GitLab specifically as an alternative: GitLab made it very clear a few years ago that they weren't particularly interested in hosting large-scale free projects when they introduced the Open Source Program as the only path to using GitLab for FOSS. I've heard over and over again that this process is painful and not worth the effort, and it has a bunch of extra requirements that would likely be dealbreakers for Mozilla [0]:
* "the Open Source Project does not, and does not seek to, generate profit from the sale or licensing of the Open Source Software to which the Open Source Project relates, or the sale of any services related to such Open Source Software;"
* "The Open Source Project agrees not to (nor to authorize any third party to): ... (b) modify or create any derivative works of the GitLab Software ... (d) copy ... the GitLab Software"
That last part is especially problematic for everyone: in order to use GitLab.com for a FOSS project you have to renounce your right to modify (or authorize others to modify) or to copy the FOSS version of GitLab. This might have just been lawyers adding boilerplate without thinking it through, but that in itself is evidence of a major problem at GitLab.
So, GitLab is out. Aside from GitLab Mozilla could have chosen maybe Codeberg, but with the entire point being to remove barriers to new contributors it makes sense to go with the option that almost all such possible contributors are already on.
I get moving to Github being a change but I'd imagine the real story is the move from mercurial to git, although I'd guess the the social considerations might have influenced the technical decisions.
kgwxd 11 hours ago [-]
Anyone that couldn't overcome those "hurdles" shouldn't even be filing bug reports, let alone modifying code.
Kuinox 15 hours ago [-]
It's good that they fixed one of the major tech debt for contributing to firefox.
When I tried a few years ago, mercurial took multiple hours to clone, and I already had to use the unofficial git support in order to have things working before the end of the day.
Their docs was also a mess back then and made me recompile everything even if it wasnt needed.
upcoming-sesame 11 hours ago [-]
Why did they choose the mozilla-firefox org as opposed to the already existing mozilla org ?
Different access rules, I guess. Or maybe they wanted some separation from the existing org so the custom automation has no chance of doing collateral damage.
alpha_trion 11 hours ago [-]
That's an excellent question
mritzmann 15 hours ago [-]
What is the source of “Firefox Moves to GitHub”? It could be a mirror, just like Linux also has an mirror on GitHub.
It’s interesting how pull requests remain the only tab (apart from code) that cannot be disabled by the repo owners.
I get it from GitHub’s perspective, it’s a nudge to get people to accept the core premise of ”social coding” and encouraging user pressure for mirrored projects to accept GitHub as a contribution entrypoint. I’m impressed by their successes and would attribute some of that to forced socialization practices such as not allowing PRs to be disabled. I’ve grown to dislike it and become disillusioned by GitHub over the course of a long time, but I’m in awe of how well it has worked for them.
Now, both the desktop and the mobile version will be on Github, and the "issues" will stay on Bugzilla.
This will take advantage of both GitHub's good search and source browsing and Git's familiar system.
As a former Firefox and Thunderbird contributor, I have to say that I used local search instead of trying to find something on the mozilla-central website.
Of course, when you're actively developing software, you search inside your IDE, but allowing to find things easily on the website makes it more welcoming for potential new contributors.
adrian17 15 hours ago [-]
> I have to say that I used local search instead of trying to find something on the mozilla-central website.
On the contrary, I find searchfox to be the best code navigation tool I used. It has nice cross-language navigation features (like jumping from .webidl interface definition to c++ implementation), it has always-on blame (with more features too) and despite that it's really fast and feels extremely lightweight compared to GitHub interface. I really wish I had this with more projects, and I'll be sad if it ever dies.
antalis 13 hours ago [-]
Searchfox didn't exist back then, "there [was] only xul", I mean MXR of course.
Then MXR got replaced by DXR, itself replaced in 2020 by Searchfox (introduced in 2016).
> This will take advantage of both GitHub's good search and source browsing and Git's familiar system.
The source browsing has detoriated severely relatively recently IME, to the point where i can't be called "good" anymore.
It now loads asynchronously (requiring js) and lazily, randomly breaks on shaky connections and in-page search is broken.
The recent issues/PRs revamp is also a pretty major step back. Try searching in PRs with all uBlock Origin lists enabled.
mlenz 17 hours ago [-]
Great to see, but I wonder what lead to the decision of creating a new org instead of using github.com/mozilla
moontear 17 hours ago [-]
Without knowing their reason, there are a few things tied to the org where multiple orgs make sense. If you do SSO for example you tie the org to a SSO provider, you can’t tie „just a few users“ to the SSO provider (afaik). The Firefox repo may have totally different authentication / users than the main Mozilla repo.
pornel 13 hours ago [-]
The GitHub SSO is annoying. I can't even view public issues if I'm logged in to GitHub, but haven't recently re-authenticated with SSO.
GitHub also has a lot of features and authentication scopes tied to the whole org, which is pretty risky for an org as large as Mozilla.
GitHub are terrible at this, because you can't have levels other than Org and Repository. And many things (SSO, visibility rules, common configs) are on the org level.
Unfortunately often the cleaner option is to create a separate org, which is a pain to use (e.g. you log in to each separately, even if they share the same SSO, PATs have to be authorised on each one separately, etc).
In Gitlab, you would have had one instance or org for Mozilla, and a namespace for Firefox, another one for other stuff, etc.
captn3m0 16 hours ago [-]
There is an “Enterprise” level above the org, but that obviously needs an Enterprise account. It lets you manage some policies across multiple orgs, including membership.
sofixa 16 hours ago [-]
But it still requires multiple orgs, and the UX is still poor.
It's like AWS accounts vs GCP projects. Yeah, there are ways around the organisational limitations, but the UX is still leaky.
zajio1am 12 hours ago [-]
To me it seems absurd that such organization like Mozilla uses third-party hosting like GitHub instead of something self-hosted or at least running under their own name. I understand that one-person projects use GitHub, but forcing contributors to make account with third-party service seems contributor-hostile.
garganzol 9 hours ago [-]
If it is an open source project then why not. This gives some visibility and welcoming openness to the project where everyone can contribute.
thrdbndndn 17 hours ago [-]
Correct me if I'm wrong, IIRC the previous "master" branch is `mozilla-central`.
Now it has "main" and "autoland", what are they? Which one is the equivalent of mozilla-central before?
chme 16 hours ago [-]
Not a firefox dev, but pretty sure its 'main'
The "new" git default branch name is 'main' and 'autoland' existed before next to 'mozilla-central' and is the one where commits usually appear first.
jamienicol 16 hours ago [-]
I am a Firefox developer, and you're spot on. Previously there were separate hg repos for central, beta, release. I think ESRs too. And autoland. Now they're all branches in the same repo, and central is renamed main.
Commits land in autoland and get backed out if they cause test failures. That's merged to main ~twice per day when CI is happy
thrdbndndn 15 hours ago [-]
Thanks for the clarification!
I've mostly encountered these branches/repos when checking commits linked to Bugzilla tickets, and I don't recall seeing "autoland" show up too much in those cases.
CorrectHorseBat 17 hours ago [-]
So they moved from hg to git? Or is this just an official mirror
shit_game 17 hours ago [-]
firefox development has been moved from mercurial to git since early november of 2023
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.
Kuinox 16 hours ago [-]
I tried to contribute a few years ago.
The mercurial clone was taking multiple hours.
They already had an non official git, which took 15 minutes to clone.
dgoldstein0 16 hours ago [-]
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
arp242 15 hours ago [-]
They had a release just a few days ago. It's definitely not abandonware.
swiftcoder 14 hours ago [-]
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.
arp242 14 hours ago [-]
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?
IshKebab 17 hours ago [-]
They supported Git and Hg until now. This means they are dropping Hg support.
sfink 8 hours ago [-]
Not yet at least. Currently both are still supported, it's just that the core repo is now in git syncing to hg rather than the other way around.
But I think hg support is going away. We hg enthusiasts at Mozilla are mostly fleeing to Jujutsu.
noobermin 11 hours ago [-]
I guess the dream is dead. Even in open source, we have consolidation with no real hard monetary markets involved.
EDIT: skimming these comments, I like how none of the top comments are talking about the bigger story here which is the move away from mercurial to git and instead everyone is focusing on github itself. This has essentially sealed hg away to obscurity forever. Do people not realise git is a program that runs on your computer and github is just a service that uses git? May be this is an old man gripe at this point but I'm surprised at the lack of technical discussion around this.
dzaima 10 hours ago [-]
This is far from the first project to move from hg to git; many people probably just generally expect that to happen upon any source code management change for anything still using mercurial, which has already been effectively dead for most people for years.
noobermin 9 hours ago [-]
My point doesn't really dispute that hg is dead "for most people" whatever that means, it's just that what the hg people could point to in the past was firefox, but now they've lost that example. Now, we can surely say it is dead.
To be frank, I know of no other major project that used hg. In fact, I think firefox was how I learned about it in the first place many years ago.
garganzol 9 hours ago [-]
I cannot imagine moving to Git from Mercurial. Git looks clunky from my perspective. Yes, it works too, but working with Git is a usability torture, sorry but it is true. I like some Git features better though, but not most of them.
noobermin 2 hours ago [-]
My honest opinion is that I hate that git won, it's too complicated for no benefit with complexity I personally will never leverage as a scientist who doesn't work in large teams.
I use it for visibility and ease, that's all. Otherwise I personally dislike it.
static_motion 5 hours ago [-]
I'm a pretty young developer and git is the only VCS I'm familiar with, and even though it has its quirks I find it quite powerful and a perfectly adequate tool for the job. In what way is Mercurial better?
probably_wrong 4 hours ago [-]
IMO Mercurial is (was?) more user-friendly.
Here's a quick example: when I create a Mercurial repository Mercurial doesn't say anything, while Git yells at me that it's using "master" as its branch name but I can change it with a cryptic command. After a first commit for a file Mercurial once again doesn't say anything, while Git gives me three lines of information including the permissions for the file I just added. Editing and committing a file in Mercurial with "hg commit" yields (again) nothing, while typing "git commit" in Git let's me know that it knows there's a modification but it won't go through until I "stage my change for commit".
Now, imagine you're a new user. Mercurial just did what I asked, and it even guessed that "hg commit" should mean "commit everything that's been modified". Git, on the other hand, has yelled at me about default branch names (what's a branch?!), file permissions, and bickered about me not staging my commit (what's a stage?!!). They both did the same thing but, for a new user, Mercurial did it in a friendlier way.
dzaima 12 minutes ago [-]
Heh, I've never noticed git commit including new file permissions on commit; definitely confusing/useless. Don't think "it prints less information" in general is a particularly good argument for user-friendliness though; if anything, it's the exact opposite.
Trying out hg for the first time - "hg init"; create file; "hg commit" prints a "nothing changed" and I have no clue how to get it to commit my file! Whereas git it says 'use "git add <file>..."', and, as it's required for starting tracking a file, it's not unreasonable that it is for updating too.
So in hg you have to explicitly think about file tracking and get changes for free, whereas in git you have to explicitly think about changes and get tracking for free.
Git's staging, messy as it is (and with some utterly horrible naming), is extremely powerful, and I wouldn't accept any VCS without a sane simple equivalent. Extremely do not like that "hg commit -i", adding some parts manually, and deciding that I actually need to do something else loses all the interactive deciding I've done (maybe there's a way around that, but hey if so it's bad user-friendliness; didn't find any useful info in --help or "man hg"). In my workflow I basically always have some changes that I don't want to yet commit.
I haven't worked for Mozilla since 2021, but back then the branches named after trees were used as feature branches for large projects, at least until those projects were in a good enough state to cleanly merge back into trunk without breaking CI.
nolok 12 hours ago [-]
I hope the bugzilla stay there even if only read only. There is a lot of historical data in there, especially for the web which was built as a "ad-hoc" platform, many times when you wonder why does X the answer can only be found in bugzilla (which will explain that some random website that used to be major but doesn't even exists anymore, did something for some browser that used to be major but doesn't even exists anymore).
sfink 9 hours ago [-]
Bugzilla is still the bug tracker for Firefox. I know if no plans to change that. (Github issues are not being used for the Firefox repo.)
fergie 10 hours ago [-]
Bugzilla was really good, and in retrospect decades ahead of its time. There is probably no self hosted bug tracker that comes close (or it there?)
tgsovlerkhgsel 16 hours ago [-]
On one hand, centralization at a commercial provider isn't great.
On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.
elric 14 hours ago [-]
> Just finding the repo is often a frustrating exercise
Surely most open source projects have a link to their source code? Whether it's github, gitlab, sourcehut, or anything else?
LegionMammal978 8 hours ago [-]
Many GNU and GNU-adjacent projects will happily list their release tarballs, but make it annoyingly difficult to find the underlying repos that most of them use. Usually the link is squirreled away somewhere in the "contributing" guidelines.
mdaniel 7 hours ago [-]
AFAIK https://savannah.gnu.org is the "sourceforge" for GNU projects. I was thrilled when they stood up a GitLab instance but recently locked it down so one can't even browse without being logged in https://emba.gnu.org/explore -> sign in
smallnix 16 hours ago [-]
I wish I could search on GitHub without logging in
hedayet 15 hours ago [-]
I wish that too, and I’ve always wanted to offer features like this in everything I build.
But it’s a lot of work to prevent abuse, especially for resource intensive features when supporting unsigned-in use cases.
This from a company that uses Ruby for their webapp and hosts probably one of the bigger CI build farms probably in the world. I have a very hard time crying because they have to run a beefy search cluster. I would guess that a very non-trivial portion of the horsepower for such a thing is about ingest of the constant updates moreso than the actual search part
bingemaker 13 hours ago [-]
They already have an org github.com/mozilla. Why didn't they move ff source there?
upcoming-sesame 11 hours ago [-]
Why did they use mozilla-firefox org name instead of the already existing https://github.com/mozilla one ?
thund 7 hours ago [-]
Hate seeing how repos are so polluted by dot-files and dot-folders. I wish tools and SDKs converged into a single dot-folder, so that we could look at repos without seeing everything everywhere
bandrami 17 hours ago [-]
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.
SCdF 17 hours ago [-]
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 distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
nextaccountic 15 hours ago [-]
Unfortunately the project is not just code. It also has issues, PRs and other stuff. Github has two kinds of lock in, a) your stuff is there and if you move elsewhere you probably will wipe your issues etc (huge loss of institutional knowledge), and b) there is a network effect because everyone has a github account and people are used to just hop on a repository and file an issue (rather than being greeted by a log in page), cross-reference issues between repositories (hard to make work if repos aren't in the same site, unless both sites use some interop thing like activitypub which github will never use), etc
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
There is https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge.
Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs
SCdF 15 hours ago [-]
> Unfortunately the project is not just code.
The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled.
What you are referring to is more of a mirror-like approach usage of GitHub.
Some big repos or organizations might be able to pull this off, but good luck having a small project and then directing users to go through all of those hoops to submit issues somewhere else, open PRs somewhere else, etc.
mkingston 15 hours ago [-]
I was reading the git-bug documentation and found "bridges" to third-party platforms:
This is one area where Gerrit Code Review is (was? I don't know if it changed) is superior. It stores everything it knows about in git repositories (preferences in a separate meta git repository, comments, patches). With the right refspec, you can pull it all down and have a full backup.
sshine 16 hours ago [-]
> if github goes down you could still generate patches and email them around, and then push back to github when it's back.
You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository.
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Radicle offers one. CLI-based, too.
flohofwoe 16 hours ago [-]
> 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 filesystem works internally to be able to use it.
And having a centralized store and history helps a lot to keep a version control system conceptually simple.
baq 16 hours ago [-]
svn was not 'humming' unless you confined yourself to a very narrow set of functionality, e.g. merging was best left to experts.
flohofwoe 16 hours ago [-]
In a centralized version control system with a single history, branching and merging is also much less important.
In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.
When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:
(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.
Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.
writebetterc 16 hours ago [-]
You don't need to learn how git works internally to be able to use it. You need to know a lot about filesystems in order to use them: Folders, files, symbolic links, copy, cut, paste, how folders can exist on different devices, etc. There's just a tonne of assumed knowledge regarding them, and it's very obvious when you meet someone that doesn't have it (regular people often don't have all it).
Subversion also isn't some thing humming along invisibly in the background, it has its own quirks that you need to learn or you'll get stung.
vishnugupta 16 hours ago [-]
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.
flohofwoe 14 hours ago [-]
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.
guappa 15 hours ago [-]
Have you ever actually used svn?
flohofwoe 14 hours ago [-]
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).
nsagent 46 minutes ago [-]
Interesting. At game companies I worked at we generally used version control solutions that easily allowed storing code and assets together, such as Perforce and Alienbrain.
People could learn, if there was suddenly a need. Just like they learned the narrow workflows they use now.
laserbeam 15 hours ago [-]
> You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond.
The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.
arp242 16 hours ago [-]
"I only accept patches and bug reports over email" is just as much of a narrow set of workflows as "I only accept patches and bug reports through PRs".
account-5 16 hours ago [-]
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.
int_19h 14 hours ago [-]
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.
account-5 12 hours ago [-]
I can certainly see the appeal of having neat commits but I tend not to worry about them. On a couple of occasions, with my university writing, having a immutable history helped me figure out, for example, how something had ended up in a final draft without citation. I'd deleted the citation which was a quick URL paste in a comment block in an earlier draft, and I'd never saved it to zotero. If I'd been able to tidy up my commits I'd likely have lost it completely.
int_19h 12 hours ago [-]
The appeal depends on how messy your commits are to begin with. When you know that commit history can be rewritten later, it suddenly becomes okay to commit incomplete code that doesn't properly run or even build, effectively using git as an undo system with branching. But the resulting history is completely unsuitable for any future attempt to use `git blame` and such.
This should be one of the very first links in the readme.
dijit 16 hours ago [-]
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Embrace, Extend..
(largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).
blueflow 15 hours ago [-]
Lets pray that Microsoft won't use Github to find new ways to extract money.
wordofx 16 hours ago [-]
Build a bridge and…
frizlab 16 hours ago [-]
Like fossil?
kaichanvong 15 hours ago [-]
while --it-is possible seeing how fossil confuses, for the Github conversation, it's not really in the same category, conversation, some clever happenings happening within fossil-scm, however, it's not really the same as the problem design-led github solves given people saying downtimes; sure, git, github; however how people using github, different–similar, git, however, github.
However, were you to say liken-able (slang keywords: comparative something else--) of, "fossil with git-github", then again: no.
Good call were the conversation (comments, almost interchangeable at-times haha!) being, everyone use git for Firefox, something kinda wild-topic!
frizlab 9 hours ago [-]
I don’t get any of that.
I tried, but no, it just makes no sense.
kaichanvong 6 hours ago [-]
;( I feel for you, hopefully–you can get more out from things in the future.
littlestymaar 17 hours ago [-]
> 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.
enos_feedler 17 hours ago [-]
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.
hnlmorg 16 hours ago [-]
As a GitHub user myself, I don’t disagree with your point. However I’d like to say that this isn’t quiet as different a problem to solve as it might first appear:
The issue tracking can be a branch and then you just need a compatible UI. In fact some git front ends do exactly this.
CI/CD does already exist in git via githooks. And you’re already better off using make/just/yarn/whatever for your scripts and rely as little on YAML as possible. It’s just a pity that githooks require users to set up each time so many people simply don’t bother.
groestl 16 hours ago [-]
> And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic.
That's how we started out.
baq 16 hours ago [-]
Maybe that's the reason everything tends to get centralized.
groestl 13 hours ago [-]
It's an emergent phenomenon, it requires less energy expenditure overall. It's also the way of the Dodo.
int_19h 14 hours ago [-]
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.
enos_feedler 42 minutes ago [-]
Wouldn’t it make economic sense for a git host to emerge that just did things this way and collect big pay for it? Gits been around forever and you’re idea sounds simple enough that a market of people would probably choose it on principle. There must be something more fundamental at play here.
tigroferoce 17 hours ago [-]
GitHub is about the community. There are others alternatives, more in line with what Mozilla claim to be their view (I'm thinking to GitLab, for instance), but nothing gives you visibility like GitHub.
Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.
SCdF 17 hours ago [-]
Right, but distributed git As Torvalds Intended™ doesn't solve those problems, so it's not related.
For the actual event we are commenting on, they have disabled all features other than code hosting and PRs.
Interestingly mozilla has effectively done this here, by using a GitHub action that automatically closes any PR with a message explaining that PRs are not to be used.
It's very silly they have to do this, but at least they can I suppose.
arp242 15 hours ago [-]
GitHub has a fairly extensive API without too many limits AFAIK. You can definitely migrate all your data to $something_else if you want to.
xboxnolifes 17 hours ago [-]
Sure, but then we are no longer talking about git.
LtWorf 15 hours ago [-]
I managed to move to codeberg all my projects. There's everything except the secret deals with pypi to directly publish from github. Which is massively insecure anyway.
phire 16 hours ago [-]
People have forgotten just how bad centralised version control was in 2005.
If you weren't connected to the internet, you couldn't do a thing. You couldn't checkout. You couldn't commit. You could create branches. The only thing on your computer was whatever you checked out last time you were connected to the server.
People talk about SVN, but it wasn't that common in 2005. None of the project hosting platforms (like SourceForge) supported SVN, they were all still offering CVS. If you wanted to use SVN, you had to set it up on your own server. (From memory, google code was the first to offer SVN project hosting in mid-2006). Not that SVN was much better than CVS. It was more polished, but shared all the same workflow flaws.
Before Git (and friends), nothing like pull-requests existed. If you wanted to collaborate with someone else, you either gave them an account on your CVS/SVN server (and then they could create a branch and commit their code), or they sent you patch files over email.
The informal email pull requests of git were an improvement... though you still needed to put your git repo somewhere public. Github and its web-based pull requests were absolutely genius. Click a button, fork the project, branch, hack, commit, push, and then create a formal "pull request". It was nothing like centralised project management systems before it. A complete breath of fresh air.
chgs 15 hours ago [-]
Pull requests aren’t part of git. They are a feature of one implementation.
phire 14 hours ago [-]
This 2007 talk [1] of Linus Torvalds promoting git to Google was how many people were introduced to the concept of git in those days before GitHub, I remember watching it myself. Emails requesting other maintains to pull your branch was very much the suggested workflow around git.
And it was actually part of git. Even back in 2005, git included a script git request pull that generated these pull request emails. I'm pretty sure people called these emails "pull requests" before GitHub came along.
I am sure Sourceforge supported subversion by 2007 or 2008, I had a project there then. When was it added?
phire 11 hours ago [-]
It's hard to find dates for that type of thing (especially with sourceforge, their website seems actively mess with the wayback machine). But I dug deeper, apparently Sourceforge got support for SVN in 2006, which is a few months before google code.
2006 appears to be the year that SVN finally became somewhat mainstream, which is interesting because git was released in 2005. Github launched in 2008 and by 2009, everyone seemed to be abandoning SVN.
It feels like SVN was only really "mainstream" for about 3 years, Maybe 5 years at most; There was some early-adopter lead-up and then a long tail of repos refusing to switch to git.
IshKebab 17 hours ago [-]
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.)
qwertox 16 hours ago [-]
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.
sph 16 hours ago [-]
Given how terrible GitHub search in files is, what I usually do is clone the repo and run ripgrep.
nicce 16 hours ago [-]
If the repository is indexed, there isn’t really competitive search. You can find blog posts about it. They actually used ripgrep at some point. (not anymore I guess because too slow?).
Not sure when you tried last, but it's gotten a lot better over the years. If you need something from the latest master, you'll be able to find it.
mrweasel 15 hours ago [-]
But Github is actually pretty good at searching for something across all files in a repo.
IshKebab 13 hours ago [-]
Not remotely as good as grep.app.
qwertox 2 hours ago [-]
I was shocked at how fast I was able to find "Open an audio file and read as mono waveform, resampling as necessary" of whisperX in audio.py on grep.app.
It was instantaneous. But where do I go from there? I cannot navigate through the code. It shows me where I can find that string, but that's it. I also cannot look at blame to see when that line got edited.
Though thanks a lot for bringing this onto my radar.
throwaway290 13 hours ago [-]
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.
jimbob45 16 hours ago [-]
That exact exercise filled a quarter of my workday today.
mmis1000 17 hours ago [-]
I think it would be great if git have some kind of soft lock by default (like attach a text on some file without make it into actual commit). It could probably make peoples' live easier when you and teamates need to communicate what files you are changing thus reduce the chance of conflict.
mashlol 15 hours ago [-]
FWIW git lfs does have support for locking files.
spookie 16 hours ago [-]
Yeah, especially binaries.
mhh__ 16 hours ago [-]
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.
captn3m0 16 hours ago [-]
Not Git, but several forges are working towards an ActivityOub based federation format for these: https://f3.forgefriends.org/
eru 16 hours ago [-]
Git was invented with pull requests in mind. It's just that they were originally meant to be sent via email, not on the web.
kace91 16 hours ago [-]
Can you expand on that? I’m probably younger but I can’t imagine a more comfortable way to review code.
eru 16 hours ago [-]
Pull requests are great, but the typical github UI isn't necessarily the best way to review code.
It's often useful. But sometimes you want to use other tools, like firing up your editor to explore.
mhh__ 7 hours ago [-]
No, they're terrible. We should be reviewing stacks of commits not branches
IshKebab 3 hours ago [-]
Why? A branch is a stack of commits.
Dylan16807 1 hours ago [-]
The workflow I believe they're talking about is like a branch but you can have multiple versions of the branch as you develop and refine it.
And those updates are properly tracked by your version control, not done jankily by editing a commit and rebasing and force pushing.
baq 14 hours ago [-]
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.
mhh__ 7 hours ago [-]
Phabricator.
snickerbockers 17 hours ago [-]
ironically hardly anybody outside of the linux kernel community uses it the way it was intended lol.
Didn't all this start with Linus getting into a spat with the bitkeeper dev involving some sort of punitive measure as a response to somebody making a reverse-engineered FOSS client? I don't remember the details and I'm sure I have at least half of them wrong, but that's easily one of the most disastrous decisions in the history of the software-business right up there with valve turning down minecraft and EA refusing to make sports games for the SEGA dreamcast (that last one isn't as well known but it led to SEGA launching the 2k sports brand to which outlasted the dreamcast and eventually got sold to a different company but otherwise still exists today and is still kicking EA's ass on basketball games).
eru 16 hours ago [-]
That's how git started.
But there were already quite a handful of other distributed version control systems around by the time git showed up.
So if Linus hadn't written git, perhaps we would be using darcs these days. And then we'd be debating whether people are using darcs the way it was intended. Or bazaar or monotone or mercurial etc.
I don't think what the original authors of any one tool intended matters very much, when there were multiple implementations of the idea around.
vintermann 16 hours ago [-]
> Didn't all this start with Linus getting into a spat with the bitkeeper dev
It's a joke that the bitkeeper dev has two revision control named after him, Mercurial and Git.
bitwize 16 hours ago [-]
I've heard the one that says much like Linux, Git is named after Linus himself.
midnightclubbed 16 hours ago [-]
EA not making sports games for Dreamcast wasn’t a bad decision for EA. It cost Sega a huge amount of money to produce and license their own sports games exclusively for Dreamcast, not having EA sports was a huge blow.
And while NBA 2k destroyed NBA Live it took until 2009 for that to start happening (long after Sega ownership), mainly down to sliding standards in EA’s NBA Live titles and eventually some disastrous EA launches.
rowanG077 16 hours ago [-]
I don't see how EA creating their biggest rival is anything but a bad decision for them. Had they licenses they would have a monopoly and probably millions of more sales.
formerly_proven 17 hours ago [-]
It would've made sense to change many defaults in git for "normal users" ages ago (git 2?) instead of keeping the kernel-workflow defaults.
ratatoskrt 17 hours ago [-]
To be fair, Git itself is a bit of a pain, and GitHub's main achievement is/was to make it somewhat bearable.
casenmgreen 17 hours ago [-]
I regard the Git docs as being fully equal to scientific Wikipedia articles.
Everything is fully and completely explained, in terms which mean nothing.
eru 16 hours ago [-]
I find both Wikipedia and Git docs typically more useful than this. Much more.
"In astronomy, declination (abbreviated dec; symbol δ) is one of the two angles that locate a point on the celestial sphere in the equatorial coordinate system, the other being hour angle. The declination angle is measured north (positive) or south (negative) of the celestial equator, along the hour circle passing through the point in question."
Anyone who doesn't know what declination is, know from reading the introductory paragraph of this scientific Wikipedia article?
Anyone? no? :-)
I rest my case, m'lud.
executesorder66 10 hours ago [-]
I've never heard of it before, and it makes perfect sense what it is from that intro.
On a celestial sphere (planet, star, etc) the declination angle (being 0 is at the equator, being 90 degrees is the north pole of the sphere, being -90 degrees, is at the south pole).
You also need another angle known as the "hour angle" to locate a point on the sphere. It doesn't explain what that is, but as can be seen on Wikipedia, you can easily click on that word to go to the entire page that explains what it is.
What don't you understand?
squigz 12 hours ago [-]
> Anyone who doesn't know what declination is, know from reading the introductory paragraph of this scientific Wikipedia article?
Why should this be a metric one would want Wikipedia to meet? It's an encyclopedia, not an astronomy course.
Of course, the brilliance of Wikipedia is that if you think you can write a clearer intro, you can do so! You could even add it to the simple language version of the page - https://simple.wikipedia.org/wiki/Declination
spookie 16 hours ago [-]
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.
jamienicol 16 hours ago [-]
That problem is solved by preventing forced pushes. Rewriting history locally is encouraged.
Tainnor 14 hours ago [-]
Prevent forced pushes on protected branches (develop, main, hotfix etc.). I don't care if somebody force pushes their private feature branch.
cmrdporcupine 12 hours ago [-]
Force pushing onto PR branches is the only way to make the commit history in them sane.
But GH's PR process is broken anyways. I miss Gerritt.
baq 16 hours ago [-]
If you don't rewrite history in git, I don't want to bisect in your repos.
If you push rewritten history to master, you're a git.
Conclusion: learn your tools.
mkesper 16 hours ago [-]
The modern workflow is just to let GitHub squeeze yor shit commits into one and then rebasing that.
vvillena 5 hours ago [-]
The "squash everything" mantra turns git commit history into a series of snapshots devoid of any logical notion about how code evolves.
Squashed commits are strictly worse than plain, non-fast-forwarded merges from rebased branches.
baq 4 hours ago [-]
Depends on your commits. If it’s untested noise I’d much rather they’re squashed so bisect doesn’t meander in trash.
vvillena 4 hours ago [-]
Bisecting with --first-parent takes care of this.
baq 15 hours ago [-]
Hardly anything modern about it, but it's a way of keeping a somewhat sane history. Certainly better than merging 'fix' 'fix' 'fix comments' into master.
The thing is, we could have done better (and have been) since before git even existed.
cmrdporcupine 12 hours ago [-]
There are legit reasons to have a series of commits within one PR, and rebase and merge them as is, and use amend/fixup and force pushes to maintain them cleanly.
It's not my favourite process, but...
tester756 16 hours ago [-]
No, git's CLI is terrible mess.
mmis1000 17 hours ago [-]
In some sense, git is actually like advanced zip versioning system. A commit is literally just a snapshot of code base except it tell you what is the previous version of this version.
Also, git store the files in a smarter way so file size won't explode like zip versioning.
eru 16 hours ago [-]
> A commit is literally just a snapshot of code base except it tell you what is the previous version of this version.
Or previous versions. Plural. Yes.
Well, that's one half of git. The other half is tooling to work with the snapshots and their history, eg to perform merges.
mmis1000 10 hours ago [-]
On the other hand, the other part of git aren't really strictly work only for git. Create and apply diff also works for plain folder without git history. They are big part of the ecosystem while not bound to git in a strict way either.
ghosty141 16 hours ago [-]
I don't get this. Git is still distributed, even if the "main" repo is on github, everybody still has a local copy. You are confusing project management (which github effectively does) and git. Git is still git, github is just a project management tool with git integration.
In the Linux kernel the project management is done via email (which is also just a centralized webserver in the end), so whats the problem?
miyuru 15 hours ago [-]
The problem is lot of Dev tools has centralized on GitHub, so much so that we cannot use IPv6 only servers for development because GitHub does not support IPv6.
From what I use composer and brew relies on GitHub to work.
The reason is that it is more than code. Managing identity is hard and for many projects besides having a source of truth for the repository you also need some degree of project management (bug tracking)
And: Even though source of truth is centralized for many projects in GitHub, git still benefits from being distributed: It's the basis for "forks" on VithUb and for the way people develop. Ja jung the clone locally and committing locally and preparing the change set for review. In the CVS/SVN days one had to commit to the ce teal branch way sooner and more direct.
eru 16 hours ago [-]
Yes, in git you get the benefit of fine-grained version control while you are still exploring.
Then later on for the PR, you can sanitise the whole thing for review.
In the bad old days, you only got the latter. (Unless you manually set up an unrelated repository for the former yourself.)
NexRebular 15 hours ago [-]
It really is a tragedy that git monoculture is winning over Mercurial, Fossil and other better designed alternatives. Don't even have a nice github-like service for Mercurial anymore as Bitbucket decided to give up.
int_19h 13 hours ago [-]
This happened mostly because the benefits of those other tools over git are so marginal that they don't provide a strong motivation to pick them over git unless everything else is equal. With GitHub in the picture, everything else is not equal, and so...
BeetleB 9 hours ago [-]
I had been chronically depressed with Mercurial's decline, but now at least jj gives me hope for sanity:
Which I used until they stopped releasing prebuilt packages without subscription.
baq 17 hours ago [-]
When you clone a repo you store it on your computer, too. Don’t confuse version control with CI servers/bug trackers/software forges.
novaRom 16 hours ago [-]
Linus Torvalds is one of those people whos impact on the world is significant even if he was not driven by financial initiative. It’s crazy how much one person can change things just by solving their own problems really well.
15 hours ago [-]
lmm 17 hours ago [-]
Turns out the important part wasn't the distributed-ness at all (unless you count being able to work offline). Many such cases.
globular-toast 16 hours ago [-]
Oh it is, but I think people forget what the distributed model gets you. It isn't just about having a completely decentralised workflow. When you clone a repo you have everything you need to keep working on that project. You have your own copy of all the branches which you are free to do whatever you want with. This is what makes it fast. Every clone has a brand new master branch and you never needed to ask anyone or get agreement to get your own branch to work on. Commits on your branch will never interfere with anyone else's work. You don't need to lock files and complete your work as quickly as possible. You can do as many commits as you like, a hundred in a day is not unheard of, because it's your branch. Previously people would commit once a day at most and sometimes not even until the end of the week, which is just unthinkable to a git user. A git clone is your own personal repo which allows you to use version control before you even share anything with anyone.
eru 16 hours ago [-]
> You have your own copy of all the branches which you are free to do whatever you want with.
That's the default. But git would work just as well, if by default it was only cloning master, or even only the last few commits from master instead of the full history.
You can get that behaviour today, with some options. But we can imagine an alternate universe were the defaults were different.
Most of what you say, eg about not needing lockfiles and being able to make independent offline commits, still applies.
globular-toast 15 hours ago [-]
The point wasn't really about having your own copy of the commit history, it's about having your own copy of the refs (which is all a branch is in git). Basically, your master branch is not the same branch as GitHub's master branch or anyone else's. This is one of the things people don't really seem to understand about git. It means you don't have to do the "feature branch" thing, for example, you can just do commits on your master branch then submit a PR.
spookie 16 hours ago [-]
Yup. It's an extremely powerful workflow, you won't fear trying new ideas, you aren't fully commited to them (hehe).
cookiengineer 13 hours ago [-]
To be fair: Linus didn't predict how painful email is in 2025. Self hosting email is a useless attempt if 99% of your emails land in spam anyways, and only spammer emails land in your inbox because they pay for azure or google business accounts.
The general issue that git has is making them interact with each other, I would love for git to get distributed issues, and a nice client UI that is actually graphical and usable by non-terminal users.
There were some attempts to make this distributed and discoverable via similar seed architectures like a DHT. For example, radicle comes to mind.
But staying in sync with hundreds of remotes and hundreds of branches is generally not what git is good at. All UIs aren't made for this.
I'm pointing this out because I am still trying to build a UI for this [1] which turned out to be much more painful than expected initially.
The code is still distributed. Every git clone usually creates a new, self-preserving copy (if we ignore some special flags). The problem is those features, which GitHub is offering outside of code. And I guess the irony is that GitHubs success is probably the reason nobody is adding them to git itself. Like add some subfolders into the repo for issues, wiki, discussions, etc. and have a UI for handling them all, easy. Instead, we have forges&tools supporting separate repos with flavours of widely used formats, making everything more complicated...
vasco 17 hours ago [-]
Most people have it at least in two places if they work alone and in many places if they work with others. Having a consistent central UI doesn't take away from the distributed part, while adding a bunch of goodies.
csomar 16 hours ago [-]
distributed # decentralized. The point of distributed is to keep a copy of your own. The point of decentralized is to not have a central point of authority.
contravariant 15 hours ago [-]
I'm fine with it as long as ssh still works.
m-schuetz 15 hours ago [-]
I have no use for a distributed source control system. I want my stuff consolidated at one place.
starspangled 14 hours ago [-]
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.
ahoka 16 hours ago [-]
Git wouldn't be mainstream without GitHub though.
dijit 16 hours ago [-]
It might feel like that now, but in 2011 github was just one of a bunch of code forges and at the time they were all similar in quality.
Gitorious was chosen for the meego/maemo team for example.
petepete 16 hours ago [-]
In those days GitHub probably had more eyes on it in a day then Gitorious did in a quarter.
And I am one of the people saddened by the convergence on a single platform.
But you can't deny, it's always been pretty great.
TuxSH 7 hours ago [-]
> And I am one of the people saddened by the convergence on a single platform.
Hardly surprising, though, social networks are prone to centralization (due to network effect), and GitHub & its competitors (anything that offers git repos + issue tracking + fork-ability, really) are social networks.
Also, GitHub offering private repos for free right after they got acquired by Microsoft helped a lot. A lot of people, myself included, were using gitlab.com for private repos at that time
OtomotO 16 hours ago [-]
I find this comment really interesting, because NONE of my clients in the last 10 years of (self-) employment had even a single codebase on GitHub.
I am contributing to a few open source projects on GitHub here and there though.
voidspark 15 hours ago [-]
GitHub is not Git.
Git is by far the most widely used VCS. The majority of code hosting services use it.
OtomotO 7 hours ago [-]
Yes, I am aware. I didn't claim anything else.
My clients don't use GitHub.
Most of my clients do use Git. (some use other VCS)
What made you think I thought differently?
voidspark 5 hours ago [-]
Because the comment you replied to never mentioned GitHub. I thought you didn’t know the difference. Linus created Git.
OtomotO 3 hours ago [-]
I see. Just fat fingers
Double_a_92 13 hours ago [-]
How is it a single place if every dev has a full copy of the repository? Also unless it's some software that each user customizes and builds for themselves, you still need some kind of way to tell which is the official version.
pretty cool that we have a distributed version control system but people still complain that the distributed version control system is not itself hosted on a public distributed version control system like a ouroubouros of transparency so transparent that you can't even see the thing and you lose it because you don't know where it is and you lose yourself in a maze of infinitely branching dependency tree of self hosted bug trackers and federated account systems so that you can keep track of your bug reports and compile the bug tracker from scratch and all of a sudden you are building linux and you want to report a linux bug, but you need to send an email so you build an HTTP server but you don't have a C compiler yet so you download the latest C source code, but you don't have a C compiler to compile it, so you just make a github account and learn to compromise on your ideals welcome to adulthood.
Barrin92 16 hours ago [-]
It's no more surprising than the fact that we invented distributed protocols to talk online and yet people use gmail or Facebook rather than sending data over the wire themselves.
People who are very insistent on distributed solutions never seem to understand that the economic, social and organizational reasons for division of labor, hierarchy and centralization didn't suddenly go away.
littlestymaar 17 hours ago [-]
Moving to git is understandable (Mozilla was using mercurial) but Github, really?
It's not like the hairy C++ code base of Firefox will suddenly become less scary and attract more open source developers simply because it's moving to Github.
moralestapia 17 hours ago [-]
Care to explain?
joha4270 17 hours ago [-]
If GitHub went down, how much would it impact the open source world?
Sure, there would be local copies everywhere, but for a distribution version control system, it's pretty centralized at GitHub
kgeist 17 hours ago [-]
If GitHub went down, the code would be fine (just announce a new official URL), but the main thing that would be lost is issues and pull requests. Maybe Git should add official support for issues and pull requests in its metadata to be fully decentralized.
nurumaik 16 hours ago [-]
Fully decentralized metadata so we can finally have merge conflicts in PR comments while discussing merge conflicts
joha4270 15 hours ago [-]
Yes, as a I mentioned there is plenty of local copies of the code floating around.
Everything else... as the original comment said, is pretty centralized for a decentralized system.
moralestapia 9 hours ago [-]
>for a distribution version control system, it's pretty centralized at GitHub
This is what I don't get ... what is the alternative to GitHub?
aucisson_masque 17 hours ago [-]
Linus Torvalds invented git, which is what's used by GitHub and others like gitlab.
moralestapia 9 hours ago [-]
I know that, I just didn't get this part "and 20 years later we all use it to store our code in a single place".
And as I can see here, no one else did ...
sorbusherra 17 hours ago [-]
which is also owned by microsoft, that uses github data to train large language model. So, after decades of trying to kill linux and sabotage it, they finally figured out how to own it.
masfoobar 16 hours ago [-]
As a Free software supporter, its just a matter of time before we lose out on our freedoms. Honestly, once Linus retires I do think Linux will continue to thrive with a good team but Linux, the kernel, will either have to adapt to current times (whatever that can be in the future) or something else will replace it and, likely, some AI aspect on top.
It wont be free software and, likely, it will be Microsoft.
guappa 13 hours ago [-]
Linus doesn't care about free software. You're thinking of rms.
masfoobar 9 hours ago [-]
Last time I checked, he is happy using GPL (even if he did stay over v2)
octocop 15 hours ago [-]
Nice, I was just checking yesterday to find the source code of firefox. Even if it is only a mirror it's a nice step to make it more available I think.
edelbitter 14 hours ago [-]
So no IPv6 in the foreseeable future?
InTheArena 6 hours ago [-]
as a side note - I love the new bookmark tabs feature. About time :-)
The bad news is that their build system is extremely hand-rolled, and so if it works for you, count yourself lucky, because when it doesn't work you're in for 4 hours of python hell
nikolayasdf123 13 hours ago [-]
nice, GitHub is defacto place to keep and release code
5 hours ago [-]
IshKebab 17 hours ago [-]
Not for PRs or issues though which are arguably the biggest reasons to use GitHub. Still this is definitely an improvement.
baq 17 hours ago [-]
Which is fascinating since both suck. Gerrit (replace with whatever if you please) is a much better change submission experience and basically anything else is a better bug tracker.
The killer feature is collocation of features to a single forge, combined with a generous free tier it’s the windows xp of the ecosystem: everybody has it, everybody knows it, almost nobody knows anything else.
elric 14 hours ago [-]
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.
IshKebab 13 hours ago [-]
Count yourself lucky you haven't had to use Jira! Or bugzilla for that matter.
I agree it is rather basic but I don't see how it's hard to navigate.
> accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage.
I don't think that really happens based on what I've seen of other huge projects on GitHub.
elric 12 hours ago [-]
> Count yourself lucky you haven't had to use Jira! Or bugzilla for that matter.
Jira and bugzilla are vastly superior to GH Issues.
Jira doesn't even deserve 10% of the hate it gets. Most of what makes Jira awful is the people using it. Bugzilla is getting a bit long in the tooth, but at least it's still free and open source.
IshKebab 11 hours ago [-]
> Jira and bugzilla are vastly superior to GH Issues.
I think you're in the tiny minority with that opinion.
> Most of what makes Jira awful is the people using it.
Not even close. Yes, people aren't good at administering it, but there are soooo many reasons that it's shit apart from that. Not least the hilarious slowness. Jira Cloud is so slow that not even Atlassian use it.
Also I don't think you can just say "you're holding it wrong". Part of the reason people screw up Jira configs so much is that it makes it so easy to screw them up. You can't separate the two.
> but at least it's still free and open source.
Just being open source doesn't make something good.
elric 11 hours ago [-]
> I think you're in the tiny minority with that opinion.
I'm not. The whole "I hate Jira thing" is a meme among a very vocal minority of tech enthusiasts. They don't have tens of millions of users because Jira is awful. The reason why so many people cry about it (apart from the meme-factor) is that people conflate Jira with their team's failed approach at scrum.
Sure, it has rough edges, and sure, Atlassian as a company sucks. I have a bug report open on their Jira for some 20 years and I don't think it will ever get fixed. And yes, Jira Cloud is very slow, it's ridiculous. And in spite of that, GH Issues is still objectively worse. It's so far behind in terms of features that it isn't even a fair comparison.
bigstrat2003 6 hours ago [-]
> I'm not. The whole "I hate Jira thing" is a meme among a very vocal minority of tech enthusiasts. They don't have tens of millions of users because Jira is awful. The reason why so many people cry about it (apart from the meme-factor) is that people conflate Jira with their team's failed approach at scrum.
Strongly agree with this. The "Jira is bad" meme is way overblown, and is driven primarily by bad choices individual Jira administrators have made. Yes, you can turn Jira into a hellscape. You can also turn any ticket system into a hellscape if it gives you enough ability to customize it. The problem isn't Jira, the problem is companies who have a terrible workflow and torture Jira into a shape that fits their workflow.
IshKebab 3 hours ago [-]
That's merely one reason why Jira is bad. It doesn't explain why Jira Cloud is so abysmally slow for example.
IshKebab 6 hours ago [-]
> The whole "I hate Jira thing" is a meme among a very vocal minority of tech enthusiasts.
It absolutely isn't. My colleagues are not very vocal tech enthusiasts and they hate it too.
> They don't have tens of millions of users because Jira is awful.
They have tens of millions of users because Jira isn't awful for the people paying for it. But those people aren't actually using it to create & read bugs. They're looking at pretty burndown charts and marveling at the number of features it has.
It's classic enterprise software - it doesn't need to be good because it isn't sold to people actually using it.
dblohm7 8 hours ago [-]
Mozilla's Bugzilla instance is not an out-of-the-box installation of Bugzilla. It's awesome IMHO. I use GitHub issues now, and it pales in comparison. I miss bugzilla.mozilla.org every day.
matkv 16 hours ago [-]
So is this now just a mirror? I'm not sure what the point of moving to GitHub was then.
IshKebab 13 hours ago [-]
It's the primary repo rather than a mirror, but yeah I agree it they don't get most of the benefits. Moving issues and PRs is probably an enormous effort so I get why they aren't doing it all at once.
rvz 16 hours ago [-]
Centralizing everything to GitHub really isn't a good idea given their frequent incidents every week.
cubefox 13 hours ago [-]
I assume this is now one of the largest (lines of code) projects on GitHub.
github.com broke noscript/basic (x)html interop for most if not all core functions (which were working before). The issue system was broken not that long time ago.
And one of the projects which should worry about, even enforce, such interop, moving to microsoft github...
The internet world is a wild toxic beast.
17 hours ago [-]
roschdal 14 hours ago [-]
Firefox moves to GitHub. Now someone better make a fork to make a proper web browser, small, fast, lean and without bloat and surveillance.
mhh__ 16 hours ago [-]
Inevitable. GitHub is a good platform in need of some proper dev workflows (pull requests are atrocious, branches footguns, yml driven CI is a noose) but they've obviously won.
jopsen 15 hours ago [-]
I don't Firefox is moving to Github Actions anytime soon. I was pretty involved with the TaskCluster setup years ago, and it still seems to be running a bunch of CI things.
mozilla-central has a LOT of tests -- each push burns a lot of compute hours.
sfink 6 hours ago [-]
Yes. All CI is remaining in TaskCluster. Bugs are remaining in bugzilla, not GH issues. Code review is remaining in Phabricator (pre-Phorge fork), pushing in Lando (a custom layer).
Some associated projects are using more GitHub stuff.
frshOffTheBoat 5 hours ago [-]
[dead]
mentalgear 16 hours ago [-]
Would have been great if they used an European alternative ( like Codeberg ).
selectnull 16 hours ago [-]
Mozilla is US organization, why would they care to?
neilv 15 hours ago [-]
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 Microsoft.
(FWIW, Microsoft has been relatively gentle or subtle with GitHub, for whatever reason. Though presumably MS will backstab eventually. And you can debate whether that's already started, such as with pushing "AI" that launders open source software copyrights, and offering to indemnify users for violations. But I'd guess that a project would be pragmatically fine at least near term going with GitHub, though they're not setting a great example.)
selectnull 14 hours ago [-]
Given the Mozilla direction lately, the last thing they want is good data protection laws.
fsflover 14 hours ago [-]
This is a huge exaggeration, borderline dishonest attack.
selectnull 13 hours ago [-]
Time will tell. I would love to be wrong.
fsflover 10 hours ago [-]
You didn't even provide any actual context making it impossible to argue with you. HN should have better conversations than shallow dismissals (according to the guidelines).
neilv 7 hours ago [-]
I sorta agree with this comment, but would rephrase that to "unclear what direction is being referred to".
(Arguing may come next, but first comes communicating.)
selectnull 6 hours ago [-]
You are completely correct, my comment was shallow and that was my fault.
Here is my opinion on Mozilla and their direction: in the previous decade (or a little bit more) or so their primary money bringer was Google, paying for the default search engine placement in Firefox. Annually, that brought about half a billion US (I don't have the exact amounts, but let's assume in that decade they should have earned a few billions).
At the same time, Firefox continuously lost market share and with that, the power to steer the web in the direction of privacy (1) and open standards (2).
(1) instead, they've acquired Anonym, an ad business which touts itself to be interested in user's privacy. color me sceptic on that one.
(2) it's all Chrome and iOS. Firefox is a lagard.
So, what has Mozilla done with the billions? Have they invested it in Firefox? MDN perhaps? Are they the web champions they have been in 2010s?
You can still argue that these points are shallow. My original comment was motivated by my disappointment in Mozilla's lost opportunity to be a fighter for an open web. Instead they have sold their soul to the highest (and only) bidder.
fsflover 5 hours ago [-]
> color me sceptic on that one.
This is fair but not sufficient to declare "the last thing they want is good data protection laws".
> it's all Chrome and iOS.
> So, what has Mozilla done with the billions?
This is also fair but has nothing to do with the data protection laws.
> Instead they have sold their soul to the highest (and only) bidder.
It seems they can't continue doing this, given the ongoing legal actions against Google. So let's see.
selectnull 5 hours ago [-]
> This is fair but...
> This is also fair but...
Ok, so we can agree that my assesment is fair, but it remains to be seen how the data protection story pans out.
>> Instead they have sold their soul to the highest (and only) bidder.
> It seems they can't continue doing this, given the ongoing legal actions against Google. So let's see.
Just to be clear: I think that Mozilla should have taken that money (and possibly more) and *invest* in Firefox and build a rainy day fund (which are coming soon). Instead, they spent it on whatevers and done a layoff.
fsflover 4 hours ago [-]
> Ok, so we can agree that my assesment is fair
My point is that your assessment is largely irrelevant to your original message about the data protection. It doesn't really support it.
selectnull 3 hours ago [-]
Right. Time will tell.
pparanoidd 16 hours ago [-]
lol codeberg is down right now, bad timing
berkes 14 hours ago [-]
I've used Codeberg for some projects and while their work and services are impressive and their progress steady and good, it's really not a proper alternative to Github for many use-cases.
"It depends", as always, but codeberg lacks features (that your use-case may not need, or may require), uptime/performance (that may be crucial or inconsequential to your use-case), familiarity (that may deter devs), integration (that may be time-consuming to build yourself or be unnessecary for your case) etc etc.
kristel100 15 hours ago [-]
Honestly surprised it took this long. For a project that depends so much on community contribution, being on GitHub just lowers the barrier for new devs. Curious to see if this revives contribution velocity.
berkes 14 hours ago [-]
In the very least, it will open up FTEs that can now work on what makes Mozilla projects unique, rather than on building and maintaining generic fundamentals.
It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.
rrr_oh_man 17 hours ago [-]
[flagged]
dtech 17 hours ago [-]
If you had checked you would've seen issues are not enabled. I assume they still use their Bugzilla
rrr_oh_man 16 hours ago [-]
> If you had checked you would've seen issues are not enabled
That was the point of the (obviously ill-received) joke.
calcifer 16 hours ago [-]
Ill-received or poorly stated? Try as I might, I can't find a joke in your comment.
nirava 16 hours ago [-]
I can. It was funny.
No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once".
arp242 15 hours ago [-]
> No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once".
Never underestimate the cynicism of HN commenters.
gbil 17 hours ago [-]
and they moved anyway the android firefox issues from github to bugzilla some time ago, it would be quite "funny" moving them back to github now
reddalo 17 hours ago [-]
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].
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.
arccy 15 hours ago [-]
If you maintain a popular project, you'll quickly find that github prs are a massive source of spam and low quality prs with people that don't even bother to follow up.
Bad PRs all around, with just a constant stream of drive by "why no merge?!?!?!" comments.
Tepix 14 hours ago [-]
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.
protocolture 17 hours ago [-]
If they truly cared about open source they would have hosted their own git on a run down pentium 2 in a nerds basement, never washed, and spent most of their time complaining online.
freddie_mercury 17 hours ago [-]
To assert that an organisation doesn't "truly" care about open source simply because they've chosen a tool that isn't is ridiculous.
Even before this Mozilla almost certainly used hundreds of closed source tools, including things like Slack, Excel, Anaplan, Workday, etc.
Lightkey 14 hours ago [-]
Using proprietary software in-house for management is one thing, forcing outside contributors to use them, another. That is why they went out of their way to avoid Slack when the time came to leave IRC behind and they chose Matrix instead.
mzi 17 hours ago [-]
Codeberg unfortunately have an abysmal uptime track record.
gsich 17 hours ago [-]
Probably only for visibility. Or MS is in the process of sponsoring them.
pndy 16 hours ago [-]
Considering image backlash they had over last year with: acquiring ad tech company created by former meta people, which in turn lead to introducing so-called "privacy preserving attribution" feature for ads tracking, changing ToS terms regarding data collection, firing CPO who was diagnosed with cancer. Then I do believe these all little changes are PR stunts with an attempt to regain trust of users who strongly criticised Mozilla in last year and earlier.
They should restructure instead, hire people who actually want to work on software and not use corporation and foundation around it as platform for their... peculiar "endeavours". But I doubt that's gonna happen - flow of Google cash and from all those naive people who think supporting Mozilla directly contributes to Firefox is too good it seems. But then it's understandable they do this - money from Google tap can get twisted.
aucisson_masque 17 hours ago [-]
> MS is in the process of sponsoring them.
Think you might be on something, with the incoming end of Google cash flow, Firefox may be in discussion with bing and that could be part of the agreement, use Microsoft server.
17 hours ago [-]
rurban 17 hours ago [-]
I maintain some project on all forges in parallel, even savannah. Savannah is even the default. But 99% of all reports and contributions are on the github mirror, 1% on savannah, 0% on gitlab and 0% on codeberg. Nobody cares about those islands.
issues are stored in git bug and automatically synced. Github is the only viable option, but you can keep the others as mirrors when github chooses to strike you.
AStonesThrow 17 hours ago [-]
> If they truly cared about open-source
Perhaps Microsoft offered to pick up the tab that Google has been paying, but is now imperiled, or at least lend some sort of financial support, and Firefox cares more about paying their bills than open source
petepete 16 hours ago [-]
I wonder how long it'll take for my PR which entirely removes the built in Pocket integration will take to be dismissed.
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
If I may - what were the significant scale challenges for self hosted solution?
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...
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.
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.
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...
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.
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.
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 (?)
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.
This might be a country-dependant thing.
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.
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.
Are you talking about Microsoft here? https://en.wikipedia.org/wiki/Microsoft#Controversies
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.
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.
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).
https://news.ycombinator.com/item?id=43971550
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.
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.
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.
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.
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?
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.
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.
I'm not claiming that my comment was 100% accurate, 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?
Which means I guess they're back on Github now.
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..)
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.
> 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? :-)
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.
GitHub issues is terrible compared to Mozilla's Bugzilla instance. It's not even close.
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
I think you can dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.
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)
There's no easy solution. Much like the recent curl security kerfuffle, the signal:noise ratio is important and hard to maintain.
Email is simple. It's just text, there's no weird javascript or html or lag. I don't have to open X11. I can just open mutt and read or write. I can type "git send-email". It's all open source, so I can read the code to understand it, and write scripting around it. It runs on any computer with ease. Even on a slow connection, it's quite speedy.
I totally agree with you about Phabricator though.
You can do nearly everything the website does entirely in the terminal.
I have some unconventional workflows. And I try not to bother anyone else with it, especially in a volunteer driven open source context. It would be selfish to do otherwise.
To be honest based on what you've written here, keeping you out of my projects sounds like a good thing. What a bunch of piss and vinegar over how other people are choosing to work in a way that works for them.
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 lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?
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.
But I just don't see how GitHub or a PR-style workflow relates. Like I said in my own reply: I think it's just because you'll receive less contributions overall. That's a completely fair and reasonable trade-off to make, as long as you realise that is the trade-off you're making.
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.
Quite obviously, any incidental friction makes this ever so slightly harder or less likely. Good contributions don't necessarily or only come from people who are already determined from the get go. Many might just want to dabble at first, or they are just casually browsing and see something that catches their attention.
Every projects needs some form of gatekeeping at some level. But it's unclear to me whether the solution is to avoid platforms with high visibility and tools that are very common and familiar. You probably need a more sophisticated and granular filter than that.
You can easily craft an email for that. No need to create a full PR.
It's that sense of superiority that pisses me off.
Many maintainers condescendingly reply "contributions welcome" in response to user complaints. People like that had better accept whatever they get. They could have easily done it themselves in all their "high quality" ways. They could have said "I don't have time for this" or even "I don't want to work on this". No, they went and challenged people to contribute instead. Then when they get what they wanted they suddenly decide they don't want it anymore? Bullshit.
You're making the assumption that these are "high quality" projects, that someone poured their very soul into every single line of code in the repository. Chances are it's just someone else's own low effort implementation. Maybe someone else's hobby project. Maybe it's some legacy stuff that's too useful to delete but too complex to fully rewrite. When you dive in, you discover that "doing it properly" very well means putting way too much effort into paying off the technical debts of others. So who's signing up to do that for ungrateful maintainers for free? Who wants to risk doing all that work only to end up ignored and rejected? Lol.
Just slap things together until they work. As long as your problem's fixed, it's fine. It's not your baby you're taking care of. They should be grateful you even sent the patches in. If they don't like it, just keep your commits and rebase, maybe make a custom package that overrides the official one from the Linux distribution. No need to worry about it, after all your version's fixed and theirs isn't. Best part is this tends to get these maintainers to wake up and "properly" implement things on their side... Which is exactly what users wanted in the first place! Wow!
FOSS maintainers are not a unified mind. The people who go "contributions welcome" and "#hacktoberfest" are somewhere near one end of the spectrum, and the folks dealing with low-effort contributions are somewhere near the other end of the spectrum.
Good maintainers may be firm but they are always nice and grateful, and they treat people as their equals. They don't beg others for their time and effort. If they do, they don't gratuitously shit on people when they get the results. They work with contributors in order to get their work reviewed, revised and merged. They might even just merge it as-is, it can always be refactored afterwards.
That's hard to do and that's why doing it makes them good maintainers. Telling people their "contributions are welcome" only to not welcome their contributions when they do come is the real "low effort".
Thank you for a clear and concise illustration of why some contributions are really not welcome.
Just about the only thing I will agree with you on is that projects should indeed make it clear what the bar for the proper contribution is. This doesn't mean never saying "contributions are welcome", if they are indeed welcome - it's still the expectation for whoever is contributing to do the bare minimum to locate those requirements (e.g. by actually, you know, reading CONTRIBUTING.md in the root of the repo before opening a PR - which many people do not.)
no, I am not obligated to merge badly written PRs introducing bugs just because I had no time to implement the feature myself
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.
No. I definitely seen people who created multitude of misleading bug reports, flood of stupid feature requests. I personally did a bit of both.
There are people who do both repetitively, fill issue reports without filling requested fields. Or open issue again when their previous report was closed.
I got once bug report where someone was ranting that app is breaking data. Turned out (after wasting my time on investigating it) that user broke data on their own with different software, through its misuse.
There were PRs adding backdoors. This is not a valuable contribution.
There were PRs done to foment useless harmful political mess.
Some people pretend to be multiple people and argue with themselves in pull requests or issues (using multiple accounts or in more bizarre cases using one). Or try to be listed multiple times as contributor.
Some people try to sneak in some intentionally harmful content one way or another.
Some contributors are NOT valuable. Some should be banned or educated (see https://www.chiark.greenend.org.uk/~sgtatham/bugs.html ).
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.
"Friction in signing up" being a big part for you is also weird, considering basically all free software GitHub alternatives (Gitea, GitLab, Forgejo) support SSO via GitHub.
Contributors who can't use GitHub because either 1) they are fresh and can't activate a new account 2) their old grandfathered account is no longer usable or 3) their old account id doxxed and they can no longer safely contribute under the old identity.
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 countries to which GitHub won't even try to SMS/call.
Remember that registering a second account would be violating GitHub ToS.
Not to mention the AI-generated security "issues" that are reported against curl, for example, suggests there can indeed be negative value for reports, and contributions.
I don't think this is the place for a debate about the overall utility of open source.
Alternatives to github
We lament Google's browser engine monopoly, but putting the vast majority of open source projects on github is just the expected course to take. I guess we'll repeat history once microsoft decides to set in the enshittification, maybe one day mobile OSes replace Windows and they're strapped for cash, who knows, but it's a centralised closed system owned by a corporation that absolutely adores FOSS
I don't mind any particular project (such as this one) being in Github and I can understand that Mozilla chooses the easy path, they've got bigger problems after all, but it's not like there are no concerns with everyone and everything moving to github
GitLab? It was awful. Slow, and paying for that kind of experience felt like a bad joke. It's much better now but it was borderline unusable back in the day.
Or SourceForge, before Git was mainstream? Also terrible.
GitHub succeeded because it quickly established itself as a decent way to host Git - not because it was exceptional, but because the competition had abysmal UX.
Unlike other lock-in-prone services, moving a Git project is trivial. If GitHub loses its advantages due to enshittification, you just move. Case in point: Mozilla hopping on and off GitHub, as this article shows.
I think the real competition began around the same time.
not really
just moving issue tracker and discussions is highly annoying
trying to get your users to move is likely hard and you will lose many
still, may be easy in comparison
A lot more contributions on GH, but the majority of them ignored guidelines and/or had low code quality and attention to detail. Just my anecdotal experience of course.
* contributors need to start somewhere, so even broken PRs can lead to having a valuable contributor if you're able to guide them.
no.
Somehow I think you're holding the difficulty scale backwards!
Being a good coder has absolutely no correlation to being good at using Mercurial.
No, but being a good coder is strongly anti-correlated with being unable or unwilling to figure out Mercurial.
I struggled to understand how the two interacted with each other, and I didn't know how to 'update my branch/pr' and I eventually just gave up.
* "the Open Source Project does not, and does not seek to, generate profit from the sale or licensing of the Open Source Software to which the Open Source Project relates, or the sale of any services related to such Open Source Software;"
* "The Open Source Project agrees not to (nor to authorize any third party to): ... (b) modify or create any derivative works of the GitLab Software ... (d) copy ... the GitLab Software"
That last part is especially problematic for everyone: in order to use GitLab.com for a FOSS project you have to renounce your right to modify (or authorize others to modify) or to copy the FOSS version of GitLab. This might have just been lawyers adding boilerplate without thinking it through, but that in itself is evidence of a major problem at GitLab.
So, GitLab is out. Aside from GitLab Mozilla could have chosen maybe Codeberg, but with the entire point being to remove barriers to new contributors it makes sense to go with the option that almost all such possible contributors are already on.
[0] https://handbook.gitlab.com/handbook/legal/opensource-agreem...
Their docs was also a mess back then and made me recompile everything even if it wasnt needed.
https://github.com/mozilla
https://github.com/torvalds/linux
// EDIT: Source: https://news.ycombinator.com/item?id=43970574
https://github.com/mozilla-firefox/firefox/blob/main/.github...
I get it from GitHub’s perspective, it’s a nudge to get people to accept the core premise of ”social coding” and encouraging user pressure for mirrored projects to accept GitHub as a contribution entrypoint. I’m impressed by their successes and would attribute some of that to forced socialization practices such as not allowing PRs to be disabled. I’ve grown to dislike it and become disillusioned by GitHub over the course of a long time, but I’m in awe of how well it has worked for them.
Now, both the desktop and the mobile version will be on Github, and the "issues" will stay on Bugzilla.
This will take advantage of both GitHub's good search and source browsing and Git's familiar system.
As a former Firefox and Thunderbird contributor, I have to say that I used local search instead of trying to find something on the mozilla-central website.
Of course, when you're actively developing software, you search inside your IDE, but allowing to find things easily on the website makes it more welcoming for potential new contributors.
On the contrary, I find searchfox to be the best code navigation tool I used. It has nice cross-language navigation features (like jumping from .webidl interface definition to c++ implementation), it has always-on blame (with more features too) and despite that it's really fast and feels extremely lightweight compared to GitHub interface. I really wish I had this with more projects, and I'll be sad if it ever dies.
Then MXR got replaced by DXR, itself replaced in 2020 by Searchfox (introduced in 2016).
https://discourse.mozilla.org/t/decommission-dxr/69475
https://billmccloskey.wordpress.com/2016/06/07/searchfox/
The source browsing has detoriated severely relatively recently IME, to the point where i can't be called "good" anymore.
It now loads asynchronously (requiring js) and lazily, randomly breaks on shaky connections and in-page search is broken.
The recent issues/PRs revamp is also a pretty major step back. Try searching in PRs with all uBlock Origin lists enabled.
GitHub also has a lot of features and authentication scopes tied to the whole org, which is pretty risky for an org as large as Mozilla.
https://wiki.mozilla.org/GitHub#other_github
https://en.m.wikipedia.org/wiki/Conways_Law
Unfortunately often the cleaner option is to create a separate org, which is a pain to use (e.g. you log in to each separately, even if they share the same SSO, PATs have to be authorised on each one separately, etc).
In Gitlab, you would have had one instance or org for Mozilla, and a namespace for Firefox, another one for other stuff, etc.
It's like AWS accounts vs GCP projects. Yeah, there are ways around the organisational limitations, but the UX is still leaky.
Now it has "main" and "autoland", what are they? Which one is the equivalent of mozilla-central before?
The "new" git default branch name is 'main' and 'autoland' existed before next to 'mozilla-central' and is the one where commits usually appear first.
Commits land in autoland and get backed out if they cause test failures. That's merged to main ~twice per day when CI is happy
I've mostly encountered these branches/repos when checking commits linked to Bugzilla tickets, and I don't recall seeing "autoland" show up too much in those cases.
https://www.phoronix.com/news/Firefox-Going-Git
But I think hg support is going away. We hg enthusiasts at Mozilla are mostly fleeing to Jujutsu.
EDIT: skimming these comments, I like how none of the top comments are talking about the bigger story here which is the move away from mercurial to git and instead everyone is focusing on github itself. This has essentially sealed hg away to obscurity forever. Do people not realise git is a program that runs on your computer and github is just a service that uses git? May be this is an old man gripe at this point but I'm surprised at the lack of technical discussion around this.
To be frank, I know of no other major project that used hg. In fact, I think firefox was how I learned about it in the first place many years ago.
I use it for visibility and ease, that's all. Otherwise I personally dislike it.
Here's a quick example: when I create a Mercurial repository Mercurial doesn't say anything, while Git yells at me that it's using "master" as its branch name but I can change it with a cryptic command. After a first commit for a file Mercurial once again doesn't say anything, while Git gives me three lines of information including the permissions for the file I just added. Editing and committing a file in Mercurial with "hg commit" yields (again) nothing, while typing "git commit" in Git let's me know that it knows there's a modification but it won't go through until I "stage my change for commit".
Now, imagine you're a new user. Mercurial just did what I asked, and it even guessed that "hg commit" should mean "commit everything that's been modified". Git, on the other hand, has yelled at me about default branch names (what's a branch?!), file permissions, and bickered about me not staging my commit (what's a stage?!!). They both did the same thing but, for a new user, Mercurial did it in a friendlier way.
Trying out hg for the first time - "hg init"; create file; "hg commit" prints a "nothing changed" and I have no clue how to get it to commit my file! Whereas git it says 'use "git add <file>..."', and, as it's required for starting tracking a file, it's not unreasonable that it is for updating too.
So in hg you have to explicitly think about file tracking and get changes for free, whereas in git you have to explicitly think about changes and get tracking for free.
Git's staging, messy as it is (and with some utterly horrible naming), is extremely powerful, and I wouldn't accept any VCS without a sane simple equivalent. Extremely do not like that "hg commit -i", adding some parts manually, and deciding that I actually need to do something else loses all the interactive deciding I've done (maybe there's a way around that, but hey if so it's bad user-friendliness; didn't find any useful info in --help or "man hg"). In my workflow I basically always have some changes that I don't want to yet commit.
Fun to get a glimpse into someone's thought process while they were working.
https://github.com/mozilla-firefox
https://wiki.mozilla.org/ReleaseEngineering/DisposableProjec...
On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.
Surely most open source projects have a link to their source code? Whether it's github, gitlab, sourcehut, or anything else?
But it’s a lot of work to prevent abuse, especially for resource intensive features when supporting unsigned-in use cases.
Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
There is https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge.
Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs
The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled.
https://github.com/mozilla-firefox/firefox
Some big repos or organizations might be able to pull this off, but good luck having a small project and then directing users to go through all of those hoops to submit issues somewhere else, open PRs somewhere else, etc.
https://github.com/git-bug/git-bug/blob/master/doc/usage/thi...
I have not tried it.
You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository.
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Radicle offers one. CLI-based, too.
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 filesystem works internally to be able to use it.
And having a centralized store and history helps a lot to keep a version control system conceptually simple.
In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.
When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:
(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.
Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.
Subversion also isn't some thing humming along invisibly in the background, it has its own quirks that you need to learn or you'll get stung.
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.
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).
The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.
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.
You might like git-bug:
https://github.com/git-bug/git-bug
This should be one of the very first links in the readme.
Embrace, Extend..
(largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).
However, were you to say liken-able (slang keywords: comparative something else--) of, "fossil with git-github", then again: no.
Good call were the conversation (comments, almost interchangeable at-times haha!) being, everyone use git for Firefox, something kinda wild-topic!
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.
The issue tracking can be a branch and then you just need a compatible UI. In fact some git front ends do exactly this.
CI/CD does already exist in git via githooks. And you’re already better off using make/just/yarn/whatever for your scripts and rely as little on YAML as possible. It’s just a pity that githooks require users to set up each time so many people simply don’t bother.
That's how we started out.
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.
Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.
For the actual event we are commenting on, they have disabled all features other than code hosting and PRs.
It's very silly they have to do this, but at least they can I suppose.
If you weren't connected to the internet, you couldn't do a thing. You couldn't checkout. You couldn't commit. You could create branches. The only thing on your computer was whatever you checked out last time you were connected to the server.
People talk about SVN, but it wasn't that common in 2005. None of the project hosting platforms (like SourceForge) supported SVN, they were all still offering CVS. If you wanted to use SVN, you had to set it up on your own server. (From memory, google code was the first to offer SVN project hosting in mid-2006). Not that SVN was much better than CVS. It was more polished, but shared all the same workflow flaws.
Before Git (and friends), nothing like pull-requests existed. If you wanted to collaborate with someone else, you either gave them an account on your CVS/SVN server (and then they could create a branch and commit their code), or they sent you patch files over email.
The informal email pull requests of git were an improvement... though you still needed to put your git repo somewhere public. Github and its web-based pull requests were absolutely genius. Click a button, fork the project, branch, hack, commit, push, and then create a formal "pull request". It was nothing like centralised project management systems before it. A complete breath of fresh air.
And it was actually part of git. Even back in 2005, git included a script git request pull that generated these pull request emails. I'm pretty sure people called these emails "pull requests" before GitHub came along.
[1] https://www.youtube.com/watch?v=4XpnKHJAok8
2006 appears to be the year that SVN finally became somewhat mainstream, which is interesting because git was released in 2005. Github launched in 2008 and by 2009, everyone seemed to be abandoning SVN.
It feels like SVN was only really "mainstream" for about 3 years, Maybe 5 years at most; There was some early-adopter lead-up and then a long tail of repos refusing to switch to git.
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.)
Edit: ripgrep was just a test
More: https://github.blog/engineering/the-technology-behind-github...
It was instantaneous. But where do I go from there? I cannot navigate through the code. It shows me where I can find that string, but that's it. I also cannot look at blame to see when that line got edited.
Though thanks a lot for bringing this onto my radar.
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.
It's often useful. But sometimes you want to use other tools, like firing up your editor to explore.
And those updates are properly tracked by your version control, not done jankily by editing a commit and rebasing and force pushing.
Note we’re talking about the GitHub UI mostly. Pulling and merging a remote branch is a basic git operation, almost a primitive.
Didn't all this start with Linus getting into a spat with the bitkeeper dev involving some sort of punitive measure as a response to somebody making a reverse-engineered FOSS client? I don't remember the details and I'm sure I have at least half of them wrong, but that's easily one of the most disastrous decisions in the history of the software-business right up there with valve turning down minecraft and EA refusing to make sports games for the SEGA dreamcast (that last one isn't as well known but it led to SEGA launching the 2k sports brand to which outlasted the dreamcast and eventually got sold to a different company but otherwise still exists today and is still kicking EA's ass on basketball games).
But there were already quite a handful of other distributed version control systems around by the time git showed up.
So if Linus hadn't written git, perhaps we would be using darcs these days. And then we'd be debating whether people are using darcs the way it was intended. Or bazaar or monotone or mercurial etc.
I don't think what the original authors of any one tool intended matters very much, when there were multiple implementations of the idea around.
It's a joke that the bitkeeper dev has two revision control named after him, Mercurial and Git.
And while NBA 2k destroyed NBA Live it took until 2009 for that to start happening (long after Sega ownership), mainly down to sliding standards in EA’s NBA Live titles and eventually some disastrous EA launches.
Everything is fully and completely explained, in terms which mean nothing.
(They ain't perfect, of course.)
"In astronomy, declination (abbreviated dec; symbol δ) is one of the two angles that locate a point on the celestial sphere in the equatorial coordinate system, the other being hour angle. The declination angle is measured north (positive) or south (negative) of the celestial equator, along the hour circle passing through the point in question."
Anyone who doesn't know what declination is, know from reading the introductory paragraph of this scientific Wikipedia article?
Anyone? no? :-)
I rest my case, m'lud.
On a celestial sphere (planet, star, etc) the declination angle (being 0 is at the equator, being 90 degrees is the north pole of the sphere, being -90 degrees, is at the south pole).
You also need another angle known as the "hour angle" to locate a point on the sphere. It doesn't explain what that is, but as can be seen on Wikipedia, you can easily click on that word to go to the entire page that explains what it is.
What don't you understand?
Why should this be a metric one would want Wikipedia to meet? It's an encyclopedia, not an astronomy course.
Of course, the brilliance of Wikipedia is that if you think you can write a clearer intro, you can do so! You could even add it to the simple language version of the page - https://simple.wikipedia.org/wiki/Declination
But GH's PR process is broken anyways. I miss Gerritt.
If you push rewritten history to master, you're a git.
Conclusion: learn your tools.
Squashed commits are strictly worse than plain, non-fast-forwarded merges from rebased branches.
The thing is, we could have done better (and have been) since before git even existed.
It's not my favourite process, but...
Also, git store the files in a smarter way so file size won't explode like zip versioning.
Or previous versions. Plural. Yes.
Well, that's one half of git. The other half is tooling to work with the snapshots and their history, eg to perform merges.
In the Linux kernel the project management is done via email (which is also just a centralized webserver in the end), so whats the problem?
From what I use composer and brew relies on GitHub to work.
https://github.com/orgs/community/discussions/10539
And: Even though source of truth is centralized for many projects in GitHub, git still benefits from being distributed: It's the basis for "forks" on VithUb and for the way people develop. Ja jung the clone locally and committing locally and preparing the change set for review. In the CVS/SVN days one had to commit to the ce teal branch way sooner and more direct.
Then later on for the PR, you can sanitise the whole thing for review.
In the bad old days, you only got the latter. (Unless you manually set up an unrelated repository for the former yourself.)
https://github.com/jj-vcs/jj
That's the default. But git would work just as well, if by default it was only cloning master, or even only the last few commits from master instead of the full history.
You can get that behaviour today, with some options. But we can imagine an alternate universe were the defaults were different.
Most of what you say, eg about not needing lockfiles and being able to make independent offline commits, still applies.
The general issue that git has is making them interact with each other, I would love for git to get distributed issues, and a nice client UI that is actually graphical and usable by non-terminal users.
There were some attempts to make this distributed and discoverable via similar seed architectures like a DHT. For example, radicle comes to mind.
But staying in sync with hundreds of remotes and hundreds of branches is generally not what git is good at. All UIs aren't made for this.
I'm pointing this out because I am still trying to build a UI for this [1] which turned out to be much more painful than expected initially.
[1] https://github.com/cookiengineer/git-evac
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.
Gitorious was chosen for the meego/maemo team for example.
And I am one of the people saddened by the convergence on a single platform.
But you can't deny, it's always been pretty great.
Hardly surprising, though, social networks are prone to centralization (due to network effect), and GitHub & its competitors (anything that offers git repos + issue tracking + fork-ability, really) are social networks.
Also, GitHub offering private repos for free right after they got acquired by Microsoft helped a lot. A lot of people, myself included, were using gitlab.com for private repos at that time
I am contributing to a few open source projects on GitHub here and there though.
Git is by far the most widely used VCS. The majority of code hosting services use it.
My clients don't use GitHub.
Most of my clients do use Git. (some use other VCS)
What made you think I thought differently?
People who are very insistent on distributed solutions never seem to understand that the economic, social and organizational reasons for division of labor, hierarchy and centralization didn't suddenly go away.
It's not like the hairy C++ code base of Firefox will suddenly become less scary and attract more open source developers simply because it's moving to Github.
Sure, there would be local copies everywhere, but for a distribution version control system, it's pretty centralized at GitHub
Everything else... as the original comment said, is pretty centralized for a decentralized system.
This is what I don't get ... what is the alternative to GitHub?
And as I can see here, no one else did ...
It wont be free software and, likely, it will be Microsoft.
The bad news is that their build system is extremely hand-rolled, and so if it works for you, count yourself lucky, because when it doesn't work you're in for 4 hours of python hell
The killer feature is collocation of features to a single forge, combined with a generous free tier it’s the windows xp of the ecosystem: everybody has it, everybody knows it, almost nobody knows anything else.
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.
I agree it is rather basic but I don't see how it's hard to navigate.
> accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage.
I don't think that really happens based on what I've seen of other huge projects on GitHub.
Jira and bugzilla are vastly superior to GH Issues.
Jira doesn't even deserve 10% of the hate it gets. Most of what makes Jira awful is the people using it. Bugzilla is getting a bit long in the tooth, but at least it's still free and open source.
I think you're in the tiny minority with that opinion.
> Most of what makes Jira awful is the people using it.
Not even close. Yes, people aren't good at administering it, but there are soooo many reasons that it's shit apart from that. Not least the hilarious slowness. Jira Cloud is so slow that not even Atlassian use it.
Also I don't think you can just say "you're holding it wrong". Part of the reason people screw up Jira configs so much is that it makes it so easy to screw them up. You can't separate the two.
> but at least it's still free and open source.
Just being open source doesn't make something good.
I'm not. The whole "I hate Jira thing" is a meme among a very vocal minority of tech enthusiasts. They don't have tens of millions of users because Jira is awful. The reason why so many people cry about it (apart from the meme-factor) is that people conflate Jira with their team's failed approach at scrum.
Sure, it has rough edges, and sure, Atlassian as a company sucks. I have a bug report open on their Jira for some 20 years and I don't think it will ever get fixed. And yes, Jira Cloud is very slow, it's ridiculous. And in spite of that, GH Issues is still objectively worse. It's so far behind in terms of features that it isn't even a fair comparison.
Strongly agree with this. The "Jira is bad" meme is way overblown, and is driven primarily by bad choices individual Jira administrators have made. Yes, you can turn Jira into a hellscape. You can also turn any ticket system into a hellscape if it gives you enough ability to customize it. The problem isn't Jira, the problem is companies who have a terrible workflow and torture Jira into a shape that fits their workflow.
It absolutely isn't. My colleagues are not very vocal tech enthusiasts and they hate it too.
> They don't have tens of millions of users because Jira is awful.
They have tens of millions of users because Jira isn't awful for the people paying for it. But those people aren't actually using it to create & read bugs. They're looking at pretty burndown charts and marveling at the number of features it has.
It's classic enterprise software - it doesn't need to be good because it isn't sold to people actually using it.
github.com broke noscript/basic (x)html interop for most if not all core functions (which were working before). The issue system was broken not that long time ago.
And one of the projects which should worry about, even enforce, such interop, moving to microsoft github...
The internet world is a wild toxic beast.
mozilla-central has a LOT of tests -- each push burns a lot of compute hours.
Some associated projects are using more GitHub stuff.
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 Microsoft.
(FWIW, Microsoft has been relatively gentle or subtle with GitHub, for whatever reason. Though presumably MS will backstab eventually. And you can debate whether that's already started, such as with pushing "AI" that launders open source software copyrights, and offering to indemnify users for violations. But I'd guess that a project would be pragmatically fine at least near term going with GitHub, though they're not setting a great example.)
(Arguing may come next, but first comes communicating.)
Here is my opinion on Mozilla and their direction: in the previous decade (or a little bit more) or so their primary money bringer was Google, paying for the default search engine placement in Firefox. Annually, that brought about half a billion US (I don't have the exact amounts, but let's assume in that decade they should have earned a few billions).
At the same time, Firefox continuously lost market share and with that, the power to steer the web in the direction of privacy (1) and open standards (2).
(1) instead, they've acquired Anonym, an ad business which touts itself to be interested in user's privacy. color me sceptic on that one.
(2) it's all Chrome and iOS. Firefox is a lagard.
So, what has Mozilla done with the billions? Have they invested it in Firefox? MDN perhaps? Are they the web champions they have been in 2010s?
You can still argue that these points are shallow. My original comment was motivated by my disappointment in Mozilla's lost opportunity to be a fighter for an open web. Instead they have sold their soul to the highest (and only) bidder.
This is fair but not sufficient to declare "the last thing they want is good data protection laws".
> it's all Chrome and iOS.
> So, what has Mozilla done with the billions?
This is also fair but has nothing to do with the data protection laws.
> Instead they have sold their soul to the highest (and only) bidder.
It seems they can't continue doing this, given the ongoing legal actions against Google. So let's see.
> This is also fair but...
Ok, so we can agree that my assesment is fair, but it remains to be seen how the data protection story pans out.
>> Instead they have sold their soul to the highest (and only) bidder.
> It seems they can't continue doing this, given the ongoing legal actions against Google. So let's see.
Just to be clear: I think that Mozilla should have taken that money (and possibly more) and *invest* in Firefox and build a rainy day fund (which are coming soon). Instead, they spent it on whatevers and done a layoff.
My point is that your assessment is largely irrelevant to your original message about the data protection. It doesn't really support it.
"It depends", as always, but codeberg lacks features (that your use-case may not need, or may require), uptime/performance (that may be crucial or inconsequential to your use-case), familiarity (that may deter devs), integration (that may be time-consuming to build yourself or be unnessecary for your case) etc etc.
It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.
That was the point of the (obviously ill-received) joke.
No serious engineer will read that line and think, "wow, how malicious of mozilla, they just made the move to close all bug reports at once".
Never underestimate the cynicism of HN commenters.
[1] https://forgejo.org/ [2] https://codeberg.org/
Bad PRs all around, with just a constant stream of drive by "why no merge?!?!?!" comments.
Even before this Mozilla almost certainly used hundreds of closed source tools, including things like Slack, Excel, Anaplan, Workday, etc.
They should restructure instead, hire people who actually want to work on software and not use corporation and foundation around it as platform for their... peculiar "endeavours". But I doubt that's gonna happen - flow of Google cash and from all those naive people who think supporting Mozilla directly contributes to Firefox is too good it seems. But then it's understandable they do this - money from Google tap can get twisted.
Think you might be on something, with the incoming end of Google cash flow, Firefox may be in discussion with bing and that could be part of the agreement, use Microsoft server.
issues are stored in git bug and automatically synced. Github is the only viable option, but you can keep the others as mirrors when github chooses to strike you.
Perhaps Microsoft offered to pick up the tab that Google has been paying, but is now imperiled, or at least lend some sort of financial support, and Firefox cares more about paying their bills than open source