(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.
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.
Mozilla has a lot more weight to throw around in incidents like this. Personally, I would never use Github. Microsoft keeps spiraling down the Enshitification drain.
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).
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.
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.
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.
> 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.
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?
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 (?)
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.
I made a search index for github repo [1] because it takes quite some time for github to load the repositories page (which is the page to allow searching),
And sometimes even using the exact repo name in Google search, I cannot see the corresponding (non-popular) repo.
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.
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.
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.
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.
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.
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 ?
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.
And is commonly used for authentication codes, and like Social Security Number, it is PII that should be default-deny.
Github seems to have no legit need for a user's phone number. Since there's not even a way to tell them to go pound sand, I'd say opting out of disclosing sensitive information they don't need by not signing in/up and equating their unreasonable demand with a ban is respectable.
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.
> 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.
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).
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
[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.
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.
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.
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.
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.
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?
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.
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.
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.
> 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.
> 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..)
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.
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? :-)
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.
> 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...
Nope, at least not this dev.
I want to take bug reports from people who can actually report something useful (not “something somewhere aint working” or “is the system OK?”), use their brain just slightly when making the report (if you got an error, it perhaps makes sense to include that message in the report, especially when you get a screen that explicitly states “please include this information in any bug reports”), and can read and pay attention to your responses when you request more information (actually answering the questions, all of them, not just one of them that they think is most relevant, or something different that they think is relevant instead) and who don't get offended when they respond to a further request for the required information with “this is getting urgent now!” and I reply with “then it is getting urgent that you send the information that I've requested twice now”¹.
> Devs want to only take bug reports from other devs
Furthermore, I've had terrible reports from devs and other technical types. Some non-technical end users have in the past sent me far better reports than some devs seem capable of. This is particularly galling because they then complain about how bad end user reports/requests are… I don't mind it from a fresh junior, but anyone else in our line of work should know better.
> It's really not that hard to sort through user bug reports…
It also isn't hard for people to properly describe the issue they are experiencing. It would be nice to be met half way. :)
TBH a lot of my irritation comes from the industry my employer operates in. While I try to stay away from the money and contracts side even more than I try to stay away from being end-user facing, I know that they often request our fees be itemised, and then expect a reduction for the bit marked “first line support” or similar because “our people will triage problems from our users and collate the details”, but their idea of “triage & collate” is just forwarding every email they get to support@ourdomain.tld… This narrow world view might not be relevant to a large public project.
> internship in messy and difficult manual labor so that devs have some real context about what it means for a job to be unpleasant
Younger me worked retail in a theme park, and did warehouse work, and had friends who managed a farm³, I have a fair idea what a hard day of work is.
----
[1] Actually, this no longer happens. My employer is bright enough that there is a buffer between me and client-facing tasks, except occasionally when something properly technical² needs discussing between their tech people and ours.
[2] Though “properly technical” can sometimes mean explaining how key-based auth works for SSH, to someone with a grandiose job title like “Infrastructure Architect”!
[3] Now that is a multi-faceted set of physical and mental complications which make my life, and those of people sending bad bug reports and change requests, look particularly easy.
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.
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.
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
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.
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.
In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.
I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process.
Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.
I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches.
So yeah, there's that.
It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.
(aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
> 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.
Fighting spam isn't done by using unfamiliar tech, but by actually fighting the spam.
With good contributor guidelines, workflows, filters, etc.
Contributions that don't adhere to the guidelines, or cannot fit in the workflow can be dismissed or handed back.
Two random examples of things I came across in PRS recently:
"Sorry, this isn't on our roadmap and we only work on issues related to the roadmap as per the CONTRIBUTION-GUIDELINES.md and the ROADMAP.md"
"Before we can consider your work, please ensure all CI/CD passes, and the coding style is according to our guidelines. Once you have fixed this, please re-open this ticket"
That is fine, a solved problem.
Using high barrier tech won't keep intentionally harmful contributions away. It won't prevent political mess or flamewars. It won't keep ranters away. It won't help with contributors feelings of rejection and so on. Good review procedures with enough resources, help prevent harmful changes. Guidelines and codes of conduct and resources and tech to enforce, help against rants, bullying or flamewars, not "hg vs git". Good up-front communication on expectation is the solution to people demanding or making changes that can never be accepted.
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.
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.
"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.
For one, it's semantic: It's only a contribution if it adds value to a project.
What you probably mean is that "not everything handed to us is a contribution". And that's valid: There will be a lot of issues, code, discussions, ideas, and what more that substract, or have negative value. One can call this "spam".
So, the problem to solve, is to avoid the "spam" and allow the contributions. Or, if you disagree with the semantics, avoid the "negative value contributions" and "allow the positive value contributions".
A part of that solution is technical: filters, bots, tools, CI/CD, etc. Many of which github doesn't offer, BTW. A big part is social and process: guidelines, expectations, codes-of-conduct, etc. I've worked in some Open Source projects where the barriers to entry where really high, with endorsements, red-tape, sign-offs, wavers, proof-of-conducts etc. And a large part is simply inevitable "resources". It takes resources to manage the incoming stuff, enforce the above, communicate it, forever, etc.
If someone isn't willing to commit these resources, or cannot, then, ultimately, the right choice to make is to simply not allow contributions - it can still be open source, just won't take input. Like e.g. sqlite.
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.
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".
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.
> 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!
Let all those "bad PRs" with useful features and fixes accumulate at your own peril. You might wake up one day and find you're not upstream anymore because someone else has merged them all into a fork. I've seen it happen.
You seem to assume that in all cases such situation would be a problem.
In fact it not always is a problem. For some I would love if someone else would maintain it, for some fork is friendly and has a bit different purpose and so on.
> 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.
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".
> 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.)
Making things clear and being honest about the scope and status of the project is always a good thing.
Dismissing users making feature requests and reporting bugs with a "PRs welcome" cliche is quite disrespectful and very much a sign of a superior attitude.
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.
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.
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.
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.
Just checked, and it looks like my GitHub account is not linked to my Microsoft account, nor does it have my phone number.
I just signed out and started the signup flow. It allows me to use an email on my own domain, and I got as far as verifying my email before I canceled the flow, and there hadn't been any requirement for phone number of Microsoft account yet.
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?
> 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.
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.
> 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
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.
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.
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.
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.
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.
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!
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.
The move to GitHub is quite disappointing. For a foundation wanting to push an open Internet and open source, moving to a proprietary forge which stands against all its core values reflects very poorly on the entire community.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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?
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.
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; echo hello>world; hg commit" prints a "nothing changed" and I have no clue how to get it to commit my file! Whereas git says 'use "git add <file>..."', and, as that's already required for starting tracking a file in both hg and git, it's not entirely unreasonable that you'll need to do "add" upon modifications 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. Obviously I'm biased, but I think "I need to tell git what changes I want committed" is a nicer model than "I need to tell hg when it should realize a file has started existing"; the former is pretty uniformly annoying, whereas I imagine the latter quite often results in adding a file, forgetting to "hg add" it, and making a bunch of commits with changes in other files as the new file is intergrated, but never actually committing the new file itself, with zero warnings.
Git's staging/index, 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 before committing, loses all the interactive deciding I've done (maybe there's a way around that, but --help and "man hg" have zero useful info on interactive mode, not even what all the different (single-char..) actions are; granted, I don't really understand "git add -i" much either, and just use a GUI when necessary). In my git workflow I basically always have some changes that I won't want to commit in the next commit.
I think you are seeing it as a software developer as opposed to (say) a biologist on the first year of their PhD who just wants to keep their scripts safe. Mercurial's strong point (IMO) was to cater to the 90% of developers who work with two-to-three colleagues on a single branch - you could always make things more complex if needed (as evidenced by Firefox doing just fine), but the defaults were always more user-friendly than git's.
For a more time-appropriate critique, this post [1] from 2012 gives an overview of what working with Git felt like at the time when git was being popularized as an alternative to Subversion (including a frequent comment of "use Mercurial instead!"). It's also worth noting that git's error messages have become more helpful since - while the documentation for git-rebase used to be "Forward-port local commits to the updated upstream head", it now reads "Reapply commits on top of another base tip".
Software developers will be the vast majority of users though, at the very least for the CLI.
Git certainly isn't anywhere close to the prettiest thing for ease-of-learning (and indeed used to be even worse), but Mercurial didn't seem particularly good either. Really for the common uses the difference is just needing to do a "git add ." before every commit, vs a "hg add ." before some.
All of my git usage has been on projects with ≤2 devs (including me; technically excluding a few largely-one-off OSS contributions of course), but I still use a good amount of local temp branches / stashes / rebasing to organize things quite often (but also have some projects where all I've ever done is "git add .; git commit -m whatever").
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.
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.
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.
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.
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).
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
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.
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.
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.
It’s still used by Meta, at any rate (albeit a very scaled version thereof). Meta picked it for their monorepo when Linus wasn’t willing to play ball on extending Git for their use case.
Is it still used there? I know they did in the past, but reading up a bit on the background on all of this I found https://github.com/facebook/sapling, and it seems that's what they're using now?
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.
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.
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
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
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.
Hard to believe it's been 27 years. I remember when it was still in beta, and how exciting it was to have an open source alternative to Internet Explorer.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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)
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
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.
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.
> 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)
> 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.
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.
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.
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.
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).
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.
> 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.
"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".
This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.
The annoying thing about Fossil is that it doesn't let you squash commits, not even in your private branches - they have some kind of philosophical point about that.
If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.
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.
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.
i rewrote the README with the goal of providing a clear overview of git-bug's features, and why you might want to use it, and ensuring that for those who are more technically inclined, things like the data model, internal architecture, and more were easy to find under the documentation folder (whether you're browsing through the files directly, or landing on //doc:README.md, which links to the files and folders under //doc.
if you think that there is information missing from the README, or hard to find in the repository (either by browsing through it, or clicking the rather prominent links from the main README), i'd welcome any suggestions in the form of a PR.
>> ...if it's the sole feature its users would care about?
The tag-line covers it pretty well I thought?
"git-bug is a standalone, distributed, offline-first issue management tool that embeds issues, comments, and more as objects in a git repository (not files!), enabling you to push and pull them to one or more remotes."
That tells you what the feature is - if you need/want a more technical overview you can still get from the `README` to `entity data model` in two clicks (Documentation > Data model).
> 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).
> Everything surrounding code: issues, CICD, etc, is obviously another story
That's what Github is though, it's not about the code itself it's about all your project management being on Github, and once you move it, moving out isn't realistic.
And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. I think we should be grateful that the core underlying protocol for the most important data has the distributed properties we want. It's a lot more than we can say vs. lots of other platforms out there.
> And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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?).
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.
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.
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.
Yes, a branch together with information about the intended point of divergence is a stack of commits. (Most of the time, the point of divergence is arrived at implicitly by specifying the intended mother branch, and git figures out the last common ancestor, ie the merge-base.) Let's call the branch-plus-point-of-divergence a 'PR branch'.
Though your 'stack of commits' is more like a 'stack of diffs' (at least in the Git sense of commit-is-a-snapshot-of-the-whole-repo.)
And actually, for better or worse, a PR branch is more expressive than a 'stack of commits', exactly for the reason you suggest: a PR branch can also contain merge commits, it doesn't have to be a linear chain.
Basically in terms of git speak branches are mutable pointers to immutable commits. (They are basically the only mutable thing in git.)
What you'd need to do to support 'stacked diffs' or 'stacks of commits' is to keep a history of what you mutable pointers were doing. It's a 'meta-git'.
Once you have that, you could build all the convenient operations on top of that abstraction.
Btw, if memory serves right, git has some plugins (or whatever these things are called, plugins or so?) for implementing the stack of commits concept.
I don't know whether they go the 'meta-git' route that I sketched, or whether they do something less abstract.
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).
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.
That's what he says, and it's a sensible thing to say to not keep focus on old grudges, but people were really exasperated with Larry McVoy back in the day so I'm not sure it's entirely historically honest!
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.
yeah but was the point of this decision that they want to fuck with SEGA, or was the point of this decision that they didn't want to invest development resources into something that they (correctly, unfortunately) expected was going to be a dead end? It would've been the right decision with what they knew at the time but looking back in hindsight they would've been far better off if they had just made a couple shovelware games for the Dreamcast if that's all it would've taken to prevent 2k sports from ever existing.
Also the last football game in the series, ESPN NFL 2k5 (actually released in 2004 a few months before they sold the studio to Take-Two) was seen as the primary reason why EA payed off the NFL to stop selling licenses to their competitors; so it's indisputable that the 2k-sports brand had a negative impact on EA's bottom line while it was still a SEGA subsidiary.
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.
"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?
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.
Well that was a whole other topic. And luckily it links to a page that explains the whole topic of what a "celestial sphere" is. Going to the page, I see I was indeed wrong about what it was, but now I see it is an abstract sphere, with a radius that can be whatever size you want, and that is centered on the Earth, or on the observer.
Once again, not so difficult to figure out even if you have no experience in the specific technical field of a Wikipedia article. So I have no idea what /u/casenmgreen's problem is.
> 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
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.
Not a single soul besides the one rewriting history knows what they're in for after the fact.
It's a recipe for disaster.
Unless you mean squashing commits, which I don't consider rewriting history, just a retelling of the fact. Still, it's something one can only do very sporadically, or at known periods of time. I
'm sure others would be more pedantic about it and this wasn't clear above.
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.
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.
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.
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.
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?
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.
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.
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...
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.
> 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.
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.
Yes, branches are just mutable pointers. The commit history is an immutable tree and has a garbage collector to clean up.
Funny enough, this is more or less exactly the architecture some of those Haskell-weirdos would come up with. It's essentially a copy-on-write filesystem.
(Haskell people are weirdos compared to good old fashioned operating system people who use C as God intended.)
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
> 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
GH have forks. Those are distributed repos. You can also sync to GitLab and similar, you can front it with the likes of Gerrit, integrate some code review UIs that actually clone code, etc.
You can exercise distributed nature of git with GitHub quite well.
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.
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.
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.
It really is a bummer that we still can't clone over IPv6 in 2025. So annoying to have to set up (and pay for) IPv4 egress proxy on so many build systems and servers just because of this.
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
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.
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 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
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.
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.
> 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.
> 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.
> 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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.)
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).
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.
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.
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.
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.
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.
(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.
[1] https://glandium.org/blog/?p=4346
Thanks for the context. IMHO I don't think Mozilla should have decided to move to a closed-source platform owned by Microsoft.
Thanks to the decentralised nature of git, this should matter only moderately.
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.
https://news.ycombinator.com/item?id=43971550
Mozilla has a lot more weight to throw around in incidents like this. Personally, I would never use Github. Microsoft keeps spiraling down the Enshitification drain.
Only for as long as GH is only used for version control; if they also start to rely on PRs or issues or whatnot, the enmeshment will become worse.
HAH!
Given that Phabricator has been discontinued, are there any plans to replace that with something else? Phorge perhaps?
Both forks coexist and pull fixes from each other.
Thanks for the added context.
If I may - what were the significant scale challenges for self hosted solution?
Again, I can only comment from the perspective of a user; I haven't worked on the VCS infrastructure.
The obvious generic challenges are availability and security: Firefox has contributors around the globe and if the VCS server goes down then it's hard to get work done (yes, you can work locally, but you can't land patches or ship fixes to users). Firefox is also a pretty high value target, and an attacker with access to the VCS server would be a problem.
To be clear I'm not claiming that there were specific problems related to these things; just that they represent challenges that Mozilla has to deal with when self hosting.
The other obvious problem at scale is performance. With a large repo both read and write performance are concerns. Cloning the repo is the first step that new contributors need to take, and if that's slow then it can be a dealbreaker for many people, especially on less reliable internet. Out hg backend was using replication to help with this [1], but you can see from the link how much complexity that adds.
Firefox has enough contributors that write contention also becomes a problem; for example pushing to the "try" repo (to run local patches through CI) often ended up taking tens of minutes waiting for a lock. This was (recently) mostly hidden from end users by pushing patches through a custom "lando" system that asynchronously queues the actual VCS push rather than blocking the user locally, but that's more of a mitigation than a real solution (lando is still required with the GitHub backend because it becomes the places where custom VCS rules which previously lived directly in the hg server, but which don't map onto GitHub features, are enforced).
[1] https://mozilla-version-control-tools.readthedocs.io/en/late...
why github and not codeberg? badwidth? $$$ from microsoft? (traffic, free training for copilot, ..)
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.
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.
This is my understanding from reading the docs just now:
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...
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.
> 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.
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?
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 (?)
I was pretty flabbergasted when I realized that if not logged in, I could no longer search a repository for code references.
You're really going to make me clone a project locally to do a search. I just end up using google to search github. It's so stupid.
Or, log in?
There is a huge irony in me logging in to this website to posit the question to you: why?
Thanks. I didn’t realize that. Migrating repos tonight.
They no longer allow sorting by number of stars in the search without being logged in either.
Stars can be bought, they aren't very reliable.
I have never noticed that and am rarely logged in.
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.
I made a search index for github repo [1] because it takes quite some time for github to load the repositories page (which is the page to allow searching),
And sometimes even using the exact repo name in Google search, I cannot see the corresponding (non-popular) repo.
[1] https://res-index.hkit.cc
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.
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.
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.
You don't need a Github account to `git clone https://github.com/some/repo`
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.
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.
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 ?
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.
And is commonly used for authentication codes, and like Social Security Number, it is PII that should be default-deny.
Github seems to have no legit need for a user's phone number. Since there's not even a way to tell them to go pound sand, I'd say opting out of disclosing sensitive information they don't need by not signing in/up and equating their unreasonable demand with a ban is respectable.
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.
> generally reputable company
Are you talking about Microsoft here? https://en.wikipedia.org/wiki/Microsoft#Controversies
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.
> 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.
It looks like patches still get submitted to another system, and github is only used indirectly for version control.
> companies that care far less about data security already have my phone number ... including my phone company.
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.
The bar is a lot lower than you think.
Tell me more. Meanwhile: https://news.ycombinator.com/item?id=43993076
Former Mozilla employee here.
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).
> 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
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
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
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.
Yeah, it's not like they care about improving the state of the open source ecosystem anyway.
GitHub has been under 3 nines for the last year for me.
I use GitHub for work, and it very frequently has outages. Not sure codeberg could be much worse tbh.
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.
Why did you omit (self-hosted) gitlab..?
[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.
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.
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.
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.
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.
> 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?
It was a guess and I never claimed it was 100% correct, and I'm happy to stand corrected. No hard feelings there.
"I guess..." != "I'm guessing..."
That's new to me. Can you expand on that a little?
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)
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.
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.
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.
> 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?
It was an, apparently very wrong, educated guess. Nothing more.
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.
Will GeckoView and Mozilla Android Components be on GitHub too?
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.
> 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..)
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.
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? :-)
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.
> 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...
Nope, at least not this dev.
I want to take bug reports from people who can actually report something useful (not “something somewhere aint working” or “is the system OK?”), use their brain just slightly when making the report (if you got an error, it perhaps makes sense to include that message in the report, especially when you get a screen that explicitly states “please include this information in any bug reports”), and can read and pay attention to your responses when you request more information (actually answering the questions, all of them, not just one of them that they think is most relevant, or something different that they think is relevant instead) and who don't get offended when they respond to a further request for the required information with “this is getting urgent now!” and I reply with “then it is getting urgent that you send the information that I've requested twice now”¹.
> Devs want to only take bug reports from other devs
Furthermore, I've had terrible reports from devs and other technical types. Some non-technical end users have in the past sent me far better reports than some devs seem capable of. This is particularly galling because they then complain about how bad end user reports/requests are… I don't mind it from a fresh junior, but anyone else in our line of work should know better.
> It's really not that hard to sort through user bug reports…
It also isn't hard for people to properly describe the issue they are experiencing. It would be nice to be met half way. :)
TBH a lot of my irritation comes from the industry my employer operates in. While I try to stay away from the money and contracts side even more than I try to stay away from being end-user facing, I know that they often request our fees be itemised, and then expect a reduction for the bit marked “first line support” or similar because “our people will triage problems from our users and collate the details”, but their idea of “triage & collate” is just forwarding every email they get to support@ourdomain.tld… This narrow world view might not be relevant to a large public project.
> internship in messy and difficult manual labor so that devs have some real context about what it means for a job to be unpleasant
Younger me worked retail in a theme park, and did warehouse work, and had friends who managed a farm³, I have a fair idea what a hard day of work is.
----
[1] Actually, this no longer happens. My employer is bright enough that there is a buffer between me and client-facing tasks, except occasionally when something properly technical² needs discussing between their tech people and ours.
[2] Though “properly technical” can sometimes mean explaining how key-based auth works for SSH, to someone with a grandiose job title like “Infrastructure Architect”!
[3] Now that is a multi-faceted set of physical and mental complications which make my life, and those of people sending bad bug reports and change requests, look particularly easy.
I understand what you're saying, but still:
GitHub issues is terrible compared to Mozilla's Bugzilla instance. It's not even close.
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.
I suspect that Firefox is not bottlenecked on number of bug reports they got.
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.
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
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.
God help the poor sod having to sort through that pile of submitted garbage.
99% of browser users shouldn't file bug reports. I'd rather wait for a high-quality report than drown in low-quality reports.
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.
In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.
I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process.
Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.
I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches.
So yeah, there's that.
It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.
(aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)
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.
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.
Although I have certainly created pull requests before that have been ignored so not sure GitHub solves this problem.
GitHub PRs don't solve anything about that, but I wouldn't have to spend (waste) time figuring out the contribution process. At least I learned a few things writing the patches. I learned nothing of value dealing with git email or Phabricator. It's just work of the boring and tedious kind.
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.
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?
It's not true that you need to start X11. GitHub's UI renders pretty well under Wayland.
Use the GitHub CLI.
You can do nearly everything the website does entirely in the terminal.
"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.
Starting X takes forever on his PDP11. Only real way to run Unix.
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.
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
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?
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.
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.
> 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.
Some contributors are NOT valuable. Some should be banned or educated (see https://www.chiark.greenend.org.uk/~sgtatham/bugs.html ).
This can be categorized as "spam".
Fighting spam isn't done by using unfamiliar tech, but by actually fighting the spam.
With good contributor guidelines, workflows, filters, etc.
Contributions that don't adhere to the guidelines, or cannot fit in the workflow can be dismissed or handed back.
Two random examples of things I came across in PRS recently:
"Sorry, this isn't on our roadmap and we only work on issues related to the roadmap as per the CONTRIBUTION-GUIDELINES.md and the ROADMAP.md"
"Before we can consider your work, please ensure all CI/CD passes, and the coding style is according to our guidelines. Once you have fixed this, please re-open this ticket"
That is fine, a solved problem.
Using high barrier tech won't keep intentionally harmful contributions away. It won't prevent political mess or flamewars. It won't keep ranters away. It won't help with contributors feelings of rejection and so on. Good review procedures with enough resources, help prevent harmful changes. Guidelines and codes of conduct and resources and tech to enforce, help against rants, bullying or flamewars, not "hg vs git". Good up-front communication on expectation is the solution to people demanding or making changes that can never be accepted.
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.
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.
> 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.
"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.
It is not wrong.
For one, it's semantic: It's only a contribution if it adds value to a project.
What you probably mean is that "not everything handed to us is a contribution". And that's valid: There will be a lot of issues, code, discussions, ideas, and what more that substract, or have negative value. One can call this "spam".
So, the problem to solve, is to avoid the "spam" and allow the contributions. Or, if you disagree with the semantics, avoid the "negative value contributions" and "allow the positive value contributions".
A part of that solution is technical: filters, bots, tools, CI/CD, etc. Many of which github doesn't offer, BTW. A big part is social and process: guidelines, expectations, codes-of-conduct, etc. I've worked in some Open Source projects where the barriers to entry where really high, with endorsements, red-tape, sign-offs, wavers, proof-of-conducts etc. And a large part is simply inevitable "resources". It takes resources to manage the incoming stuff, enforce the above, communicate it, forever, etc.
If someone isn't willing to commit these resources, or cannot, then, ultimately, the right choice to make is to simply not allow contributions - it can still be open source, just won't take input. Like e.g. sqlite.
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.
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".
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.
> 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!
> 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
Let all those "bad PRs" with useful features and fixes accumulate at your own peril. You might wake up one day and find you're not upstream anymore because someone else has merged them all into a fork. I've seen it happen.
You seem to assume that in all cases such situation would be a problem.
In fact it not always is a problem. For some I would love if someone else would maintain it, for some fork is friendly and has a bit different purpose and so on.
> 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.
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".
> 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.)
Making things clear and being honest about the scope and status of the project is always a good thing.
Dismissing users making feature requests and reporting bugs with a "PRs welcome" cliche is quite disrespectful and very much a sign of a superior attitude.
lol go closed then
Not all PRs are created equal.
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.
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.
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.
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.
Requiring a Microsoft account, and handing over my phone number is extreme friction in my book.
Just checked, and it looks like my GitHub account is not linked to my Microsoft account, nor does it have my phone number.
I just signed out and started the signup flow. It allows me to use an email on my own domain, and I got as far as verifying my email before I canceled the flow, and there hadn't been any requirement for phone number of Microsoft account yet.
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?
> 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.
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.
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.
> 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
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.
> 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
I believe GitLab post-dates GitHub, but I otherwise agree with the sentiment.
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.
How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?
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.
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.
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.
> 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.
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.
"gatekeeping good"
no.
They are everywhere. It's like a plague.
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.
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!
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.
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.
[0] https://handbook.gitlab.com/handbook/legal/opensource-agreem...
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.
The move to GitHub is quite disappointing. For a foundation wanting to push an open Internet and open source, moving to a proprietary forge which stands against all its core values reflects very poorly on the entire community.
Anyone that couldn't overcome those "hurdles" shouldn't even be filing bug reports, let alone modifying code.
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.
Why did they choose the mozilla-firefox org as opposed to the already existing mozilla org ?
https://github.com/mozilla
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.
That's an excellent question
Firefox Mobile (Fenix) had just moved to Mozilla's Mercurial mozilla-central repository after using GitHub including for issues. https://github.com/mozilla-mobile/firefox-android/wiki#upcom...
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.
> 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.
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).
https://discourse.mozilla.org/t/decommission-dxr/69475
https://billmccloskey.wordpress.com/2016/06/07/searchfox/
> 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.
What is the source of “Firefox Moves to GitHub”? It could be a mirror, just like Linux also has an mirror on GitHub.
https://github.com/torvalds/linux
// EDIT: Source: https://news.ycombinator.com/item?id=43970574
My thoughts as well, even more so after seeing the only GitHub Workflow they have is actually for closing Pull Requests with a default response:
https://github.com/mozilla-firefox/firefox/blob/main/.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.
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.
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.
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.
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.
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.
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?
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.
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; echo hello>world; hg commit" prints a "nothing changed" and I have no clue how to get it to commit my file! Whereas git says 'use "git add <file>..."', and, as that's already required for starting tracking a file in both hg and git, it's not entirely unreasonable that you'll need to do "add" upon modifications 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. Obviously I'm biased, but I think "I need to tell git what changes I want committed" is a nicer model than "I need to tell hg when it should realize a file has started existing"; the former is pretty uniformly annoying, whereas I imagine the latter quite often results in adding a file, forgetting to "hg add" it, and making a bunch of commits with changes in other files as the new file is intergrated, but never actually committing the new file itself, with zero warnings.
Git's staging/index, 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 before committing, loses all the interactive deciding I've done (maybe there's a way around that, but --help and "man hg" have zero useful info on interactive mode, not even what all the different (single-char..) actions are; granted, I don't really understand "git add -i" much either, and just use a GUI when necessary). In my git workflow I basically always have some changes that I won't want to commit in the next commit.
I think you are seeing it as a software developer as opposed to (say) a biologist on the first year of their PhD who just wants to keep their scripts safe. Mercurial's strong point (IMO) was to cater to the 90% of developers who work with two-to-three colleagues on a single branch - you could always make things more complex if needed (as evidenced by Firefox doing just fine), but the defaults were always more user-friendly than git's.
For a more time-appropriate critique, this post [1] from 2012 gives an overview of what working with Git felt like at the time when git was being popularized as an alternative to Subversion (including a frequent comment of "use Mercurial instead!"). It's also worth noting that git's error messages have become more helpful since - while the documentation for git-rebase used to be "Forward-port local commits to the updated upstream head", it now reads "Reapply commits on top of another base tip".
[1] https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi...
Software developers will be the vast majority of users though, at the very least for the CLI.
Git certainly isn't anywhere close to the prettiest thing for ease-of-learning (and indeed used to be even worse), but Mercurial didn't seem particularly good either. Really for the common uses the difference is just needing to do a "git add ." before every commit, vs a "hg add ." before some.
All of my git usage has been on projects with ≤2 devs (including me; technically excluding a few largely-one-off OSS contributions of course), but I still use a good amount of local temp branches / stashes / rebasing to organize things quite often (but also have some projects where all I've ever done is "git add .; git commit -m whatever").
Great to see, but I wonder what lead to the decision of creating a new org instead of using github.com/mozilla
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.
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.
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.
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.
They have many orgs-
https://wiki.mozilla.org/GitHub#other_github
Presumably a case of Conways.
https://en.m.wikipedia.org/wiki/Conways_Law
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.
If it is an open source project then why not. This gives some visibility and welcoming openness to the project where everyone can contribute.
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).
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.)
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?)
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?
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.
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
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.
So they moved from hg to git? Or is this just an official mirror
firefox development has been moved from mercurial to git since early november of 2023
https://www.phoronix.com/news/Firefox-Going-Git
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.
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.
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
They had a release just a few days ago. It's definitely not abandonware.
It’s still used by Meta, at any rate (albeit a very scaled version thereof). Meta picked it for their monorepo when Linus wasn’t willing to play ball on extending Git for their use case.
Is it still used there? I know they did in the past, but reading up a bit on the background on all of this I found https://github.com/facebook/sapling, and it seems that's what they're using now?
I don't know for sure today, but Sapling was mercurial-compatible, at least early in development.
They supported Git and Hg until now. This means they are dropping Hg support.
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.
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.
> 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?
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.
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
I wish I could search on GitHub without logging in
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.
They used to have 64 core 32 machine cluster just for search. You may want to reduce unnecessary search. https://github.blog/engineering/the-technology-behind-github...
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
Why is the mozilla-firefox org full of forks of the main repo named after trees?
https://github.com/mozilla-firefox
They are used for large scale landings or when a project needs to track trunk development but will churn a lot.
https://wiki.mozilla.org/ReleaseEngineering/DisposableProjec...
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.
Star Wars reference in a comment: https://github.com/mozilla-firefox/firefox/blob/917c73cfe1a5...
Fun to get a glimpse into someone's thought process while they were working.
They already have an org github.com/mozilla. Why didn't they move ff source there?
First commit: https://github.com/mozilla-firefox/firefox/commit/c4cc52826a...
Hard to believe it's been 27 years. I remember when it was still in beta, and how exciting it was to have an open source alternative to Internet Explorer.
Good times!
Why did they use mozilla-firefox org name instead of the already existing https://github.com/mozilla one ?
Why GitHub? If they truly cared about open-source they would've chosen something else, such as a self-hosted Forgejo [1], or its most common public instance Codeberg [2].
[1] https://forgejo.org/ [2] https://codeberg.org/
I would argue that part of "truly caring" about open-source is being where the contributors and community are. That's probably a large part of the move to GitHub, and neither of these other options would achieve that. As much as one can say "git is distributed, the server doesn't matter", the centre of the community very much does matter, and for better or worse that's currently Github.
We need to work on decentralisation of git forges, making it less relevant where a project is hosted by offering cross-instance collaboration and discoverability.
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.
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.
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.
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.
Codeberg unfortunately have an abysmal uptime track record.
> 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
Probably only for visibility. Or MS is in the process of sponsoring them.
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.
> 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.
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.
Centralizing everything to GitHub really isn't a good idea given their frequent incidents every week.
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.
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)
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
> 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.
https://github.com/mozilla-firefox/firefox
This mirror is just code, but Firefox has issues. They are just stored elsewhere (bugzilla)
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.
I was reading the git-bug documentation and found "bridges" to third-party platforms:
https://github.com/git-bug/git-bug/blob/master/doc/usage/thi...
I have not tried it.
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.
> 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.
> 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.
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.
svn was not 'humming' unless you confined yourself to a very narrow set of functionality, e.g. merging was best left to experts.
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.
svn was a nightmare when it came to handling conflicts. So at least for me, humming in the background wasn’t the term used for it at work.
This was only for true before svn 1.5 (before it had 'merge tracking'). Also, branching and merging by far wasn't as essential in svn as it is in a decentralized version control system like git. In a centralized version control system it works perfectly well to do all development in the main branch, and only branch off dead-end 'release branches' which are never merged back.
Tbh, I really wonder where the bad reputation of svn is coming from. Git does some things better, especially for 'programmer-centric teams'. But it also does many things worse, especially in projects where the majority of data is large binary files (like in game development) - and it's not like git is any good either when it comes to merging binary data.
https://m.xkcd.com/1597/
Have you ever actually used svn?
Yes for about 18 years(?) in the context of game development (I don't exactly remember when we had switched from cvs to svn, but it must have been around 2003..2005) in teams up to about 100 people, working copy sizes up to about 150 GB (with most of the data being binary game asset files), and everybody working on trunk (we only used branches for releases which were branched off trunk but never merged back, only cherry-picking bugfixes from the main into release branches as needed).
We used TortoiseSVN as UI which worked well both for devs and non-devs.
With this sort of setup, git would break down completely if it weren't for awkward hacks like git-lfs (which comes with its own share of problems).
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.
> 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.
"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".
This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.
The annoying thing about Fossil is that it doesn't let you squash commits, not even in your private branches - they have some kind of philosophical point about that.
If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.
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.
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.
Gitlab is working on using ActivityPub for interoperability between instances. See: https://handbook.gitlab.com/handbook/engineering/architectur...
IIRC Phabricator stored most of it's metadata in git-notes. In theory we could have been making tools compatible with such a format all this time.
>> I would love a good issue tracking system that is done entirely inside git
You might like git-bug:
https://github.com/git-bug/git-bug
Why bury this in the documentation if it's the sole feature its users would care about? https://github.com/git-bug/git-bug/blob/master/doc/design/da...
This should be one of the very first links in the readme.
hey there! i maintain git-bug, and recently trimmed down the README, which was, in my opinion, a bit too dense prior to this recent change (https://github.com/git-bug/git-bug/commit/96c7a111a3cb075b5c...).
i rewrote the README with the goal of providing a clear overview of git-bug's features, and why you might want to use it, and ensuring that for those who are more technically inclined, things like the data model, internal architecture, and more were easy to find under the documentation folder (whether you're browsing through the files directly, or landing on //doc:README.md, which links to the files and folders under //doc.
if you think that there is information missing from the README, or hard to find in the repository (either by browsing through it, or clicking the rather prominent links from the main README), i'd welcome any suggestions in the form of a PR.
>> ...if it's the sole feature its users would care about?
The tag-line covers it pretty well I thought?
"git-bug is a standalone, distributed, offline-first issue management tool that embeds issues, comments, and more as objects in a git repository (not files!), enabling you to push and pull them to one or more remotes."
That tells you what the feature is - if you need/want a more technical overview you can still get from the `README` to `entity data model` in two clicks (Documentation > Data model).
> 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).
Lets pray that Microsoft won't use Github to find new ways to extract money.
Build a bridge and…
> Everything surrounding code: issues, CICD, etc, is obviously another story
That's what Github is though, it's not about the code itself it's about all your project management being on Github, and once you move it, moving out isn't realistic.
And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. I think we should be grateful that the core underlying protocol for the most important data has the distributed properties we want. It's a lot more than we can say vs. lots of other platforms out there.
> 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.
Maybe that's the reason everything tends to get centralized.
It's an emergent phenomenon, it requires less energy expenditure overall. It's also the way of the Dodo.
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.
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.
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.
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.
It's impossible to disable PRs on GitHub, sadly. See https://github.com/dear-github/dear-github/issues/84
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.
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.
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.
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.
Sure, but then we are no longer talking about git.
Like fossil?
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!
I don’t get any of that. I tried, but no, it just makes no sense.
;( I feel for you, hopefully–you can get more out from things in the future.
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.
Pull requests aren’t part of git. They are a feature of one implementation.
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.
[1] https://www.youtube.com/watch?v=4XpnKHJAok8
git request-pull is.
I am sure Sourceforge supported subversion by 2007 or 2008, I had a project there then. When was it added?
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.
A patch over email is how git works too!
Plenty of people use Codeberg and Gitlab. And it's still distributed - I don't need to lock files and ask coworkers if I can work on them.
Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email etc.)
In Codeberg, how does one even search for files containing a given string? Probably the #1 thing I do on GitHub is searching for files in a project containing a given string.
Given how terrible GitHub search in files is, what I usually do is clone the repo and run ripgrep.
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?).
Edit: ripgrep was just a test
More: https://github.blog/engineering/the-technology-behind-github...
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.
But Github is actually pretty good at searching for something across all files in a repo.
Not remotely as good as grep.app.
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.
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.
That exact exercise filled a quarter of my workday today.
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.
FWIW git lfs does have support for locking files.
Yeah, especially binaries.
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.
Not Git, but several forges are working towards an ActivityOub based federation format for these: https://f3.forgefriends.org/
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.
Can you expand on that? I’m probably younger but I can’t imagine a more comfortable way to review code.
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.
No, they're terrible. We should be reviewing stacks of commits not branches
Why? A branch is a stack of commits.
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.
Then whence merge commits?
A branch is a commit with a hat on, strictly speaking.
Yes, a branch together with information about the intended point of divergence is a stack of commits. (Most of the time, the point of divergence is arrived at implicitly by specifying the intended mother branch, and git figures out the last common ancestor, ie the merge-base.) Let's call the branch-plus-point-of-divergence a 'PR branch'.
Though your 'stack of commits' is more like a 'stack of diffs' (at least in the Git sense of commit-is-a-snapshot-of-the-whole-repo.)
And actually, for better or worse, a PR branch is more expressive than a 'stack of commits', exactly for the reason you suggest: a PR branch can also contain merge commits, it doesn't have to be a linear chain.
They are often called stacked diffs yes.
Basically in terms of git speak branches are mutable pointers to immutable commits. (They are basically the only mutable thing in git.)
What you'd need to do to support 'stacked diffs' or 'stacks of commits' is to keep a history of what you mutable pointers were doing. It's a 'meta-git'.
Once you have that, you could build all the convenient operations on top of that abstraction.
Btw, if memory serves right, git has some plugins (or whatever these things are called, plugins or so?) for implementing the stack of commits concept.
I don't know whether they go the 'meta-git' route that I sketched, or whether they do something less abstract.
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.
Phabricator.
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).
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.
> 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.
I've heard the one that says much like Linux, Git is named after Linus himself.
That's what he says, and it's a sensible thing to say to not keep focus on old grudges, but people were really exasperated with Larry McVoy back in the day so I'm not sure it's entirely historically honest!
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.
yeah but was the point of this decision that they want to fuck with SEGA, or was the point of this decision that they didn't want to invest development resources into something that they (correctly, unfortunately) expected was going to be a dead end? It would've been the right decision with what they knew at the time but looking back in hindsight they would've been far better off if they had just made a couple shovelware games for the Dreamcast if that's all it would've taken to prevent 2k sports from ever existing.
Also the last football game in the series, ESPN NFL 2k5 (actually released in 2004 a few months before they sold the studio to Take-Two) was seen as the primary reason why EA payed off the NFL to stop selling licenses to their competitors; so it's indisputable that the 2k-sports brand had a negative impact on EA's bottom line while it was still a SEGA subsidiary.
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.
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.
To be fair, Git itself is a bit of a pain, and GitHub's main achievement is/was to make it somewhat bearable.
I regard the Git docs as being fully equal to scientific Wikipedia articles.
Everything is fully and completely explained, in terms which mean nothing.
I find both Wikipedia and Git docs typically more useful than this. Much more.
(They ain't perfect, of course.)
https://en.wikipedia.org/wiki/Declination
"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.
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?
Well, you misunderstood / mis-guessed what celestial sphere means. Interestingly enough, your mis-understanding also sort-of works.
Well that was a whole other topic. And luckily it links to a page that explains the whole topic of what a "celestial sphere" is. Going to the page, I see I was indeed wrong about what it was, but now I see it is an abstract sphere, with a radius that can be whatever size you want, and that is centered on the Earth, or on the observer.
Once again, not so difficult to figure out even if you have no experience in the specific technical field of a Wikipedia article. So I have no idea what /u/casenmgreen's problem is.
I think I see casenmgreen's is trying to get at. But they just picked an example that (to you and me) just isn't all that complicated nor bad.
> 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
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.
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.
Not a single soul besides the one rewriting history knows what they're in for after the fact.
It's a recipe for disaster.
Unless you mean squashing commits, which I don't consider rewriting history, just a retelling of the fact. Still, it's something one can only do very sporadically, or at known periods of time. I
'm sure others would be more pedantic about it and this wasn't clear above.
The modern workflow is just to let GitHub squeeze yor shit commits into one and then rebasing that.
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.
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.
Depends on your commits. If it’s untested noise I’d much rather they’re squashed so bisect doesn’t meander in trash.
Bisecting with --first-parent takes care of this.
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...
That problem is solved by preventing forced pushes. Rewriting history locally is encouraged.
Prevent forced pushes on protected branches (develop, main, hotfix etc.). I don't care if somebody force pushes their private feature branch.
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.
No, git's CLI is terrible mess.
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.
> 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.
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.
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?
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.
https://github.com/orgs/community/discussions/10539
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.
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.)
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.
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...
I had been chronically depressed with Mercurial's decline, but now at least jj gives me hope for sanity:
https://github.com/jj-vcs/jj
heptapod is GitLab with Mercurial support.
Which I used until they stopped releasing prebuilt packages without subscription.
When you clone a repo you store it on your computer, too. Don’t confuse version control with CI servers/bug trackers/software forges.
Turns out the important part wasn't the distributed-ness at all (unless you count being able to work offline). Many such cases.
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.
> 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.
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.
Yes, branches are just mutable pointers. The commit history is an immutable tree and has a garbage collector to clean up.
Funny enough, this is more or less exactly the architecture some of those Haskell-weirdos would come up with. It's essentially a copy-on-write filesystem.
(Haskell people are weirdos compared to good old fashioned operating system people who use C as God intended.)
Yup. It's an extremely powerful workflow, you won't fear trying new ideas, you aren't fully commited to them (hehe).
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.
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.
GitHub is not Git.
Git is by far the most widely used VCS. The majority of code hosting services use it.
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?
Because the comment you replied to never mentioned GitHub. I thought you didn’t know the difference. Linus created Git.
I see. Just fat fingers
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.
[1] https://github.com/cookiengineer/git-evac
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.
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.
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...
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.
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.
That gives too much credit to git and way too less to Preston-Werner, Wanstrath, Hyett, & Chacon, and many others: https://www.youtube-nocookie.com/embed/mGTpU5XUAA8
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.
I'm fine with it as long as ssh still works.
I have no use for a distributed source control system. I want my stuff consolidated at one place.
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.
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.
Git wouldn't be mainstream without GitHub though.
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.
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.
> 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
That's wrong hot take.
GH have forks. Those are distributed repos. You can also sync to GitLab and similar, you can front it with the likes of Gerrit, integrate some code review UIs that actually clone code, etc.
You can exercise distributed nature of git with GitHub quite well.
Why should we care about what Linus invented?
Care to explain?
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
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.
Fully decentralized metadata so we can finally have merge conflicts in PR comments while discussing merge conflicts
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.
>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?
Linus Torvalds invented git, which is what's used by GitHub and others like gitlab.
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 ...
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.
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.
Linus doesn't care about free software. You're thinking of rms.
Last time I checked, he is happy using GPL (even if he did stay over v2)
So no IPv6 in the foreseeable future?
It really is a bummer that we still can't clone over IPv6 in 2025. So annoying to have to set up (and pay for) IPv4 egress proxy on so many build systems and servers just because of this.
https://github.com/orgs/community/discussions/10539
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
What are 'pine', 'maple', 'holly', etc?
Internal nomenclature for feature branches.
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.
Bad Move.
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.
I assume this is now one of the largest (lines of code) projects on GitHub.
I'd bet https://github.com/brave/brave-core would top FF, since it's both chromium _and_ Brave's extra bits
A BUILD.md could be useful.
the readme is literally 21 lines long, and about 25% of them are blank lines, with the 2nd URL pointing to "how to contribute" and that link has a dedicated "how to build and run" https://firefox-source-docs.mozilla.org/contributing/contrib...
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
nice, GitHub is defacto place to keep and release code
Firefox moves to GitHub. Now someone better make a fork to make a proper web browser, small, fast, lean and without bloat and surveillance.
Not for PRs or issues though which are arguably the biggest reasons to use GitHub. Still this is definitely an improvement.
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.
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.
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.
> 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.
> 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.
> 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.
> 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.
That's merely one reason why Jira is bad. It doesn't explain why Jira Cloud is so abysmally slow for example.
> 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.
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.
So is this now just a mirror? I'm not sure what the point of moving to GitHub was then.
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.
as a side note - I love the new bookmark tabs feature. About time :-)
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.
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.
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.
Would have been great if they used an European alternative ( like Codeberg ).
Mozilla is US organization, why would they care to?
As for European specifically, maybe the commenter was talking about data protection laws. If not, maybe (in many European countries at the moment) less national or business background of ruthlessness.
I was thinking something different: I wonder whether Mozilla considered GitLab or Codeberg, which are the other two I know that are popular with open source projects that don't trust GitHub since it sold out to 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.)
Given the Mozilla direction lately, the last thing they want is good data protection laws.
This is a huge exaggeration, borderline dishonest attack.
Time will tell. I would love to be wrong.
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).
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.)
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.
> 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.
> 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.
> 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.
Right. Time will tell.
lol codeberg is down right now, bad timing
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.
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.
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.
I wonder how long it'll take for my PR which entirely removes the built in Pocket integration will take to be dismissed.