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.
If I may - what were the significant scale challenges for self hosted solution?
The obvious generic challenges are availability and security: Firefox has contributors around the globe and if the VCS server goes down then it's hard to get work done (yes, you can work locally, but you can't land patches or ship fixes to users). Firefox is also a pretty high value target, and an attacker with access to the VCS server would be a problem.
To be clear I'm not claiming that there were specific problems related to these things; just that they represent challenges that Mozilla has to deal with when self hosting.
The other obvious problem at scale is performance. With a large repo both read and write performance are concerns. Cloning the repo is the first step that new contributors need to take, and if that's slow then it can be a dealbreaker for many people, especially on less reliable internet. Out hg backend was using replication to help with this [1], but you can see from the link how much complexity that adds.
Firefox has enough contributors that write contention also becomes a problem; for example pushing to the "try" repo (to run local patches through CI) often ended up taking tens of minutes waiting for a lock. This was (recently) mostly hidden from end users by pushing patches through a custom "lando" system that asynchronously queues the actual VCS push rather than blocking the user locally, but that's more of a mitigation than a real solution (lando is still required with the GitHub backend because it becomes the places where custom VCS rules which previously lived directly in the hg server, but which don't map onto GitHub features, are enforced).
[1] https://mozilla-version-control-tools.readthedocs.io/en/late...
I used a GitLab + GitLab Runner (docker) pipeline for my Ph.D. project which did some verification after every push (since the code was scientific), and even that took 10 minutes to complete even if it was pretty basic. Debian's some packages need more than three hours in their own CI/CD pipeline.
Something like Mozilla Firefox, which is tested against regressions, performance, etc. (see https://www.arewefastyet.com) needs serious infrastructure and compute time to build in n different configurations (stable / testing / nightly + all the operating systems it supports) and then test at that scale. This needs essentially a server farm, to complete in reasonable time.
An infrastructure of that size needs at least two competent people to keep it connected to all relevant cogs and running at full performance, too.
So yes, it's a significant effort.
Firefox does indeed have a large CI system and ends up running thousands of jobs on each push to main (formerly mozilla-central), covering builds, linting, multiple testsuites, performance testing, etc. all across multiple platforms and configurations. In addition there are "try" pushes for work in progress patches, and various other kinds of non-CI tasks (e.g. fuzzing). That is all run on our taskcluster system and I don't believe there are any plans to change that.
Your guess is wrong as Firefox doesn't use GitHub for any of that, and AFAIK there are no plans to either.
The blog post linked in the top comment goes in to this in some detail, but in brief: git log, clone, diff, showing files, blame, etc. is CPU expensive. You can see this locally on large repo if you try something like "git log path/to/dir".
Add to this all the standard requirements of running any server that needs to be 1) fast, and 2) highly available.
And why bother when there's a free service available for you?
Grim.
The best reason to be using github at all is to maximize the portion of your users who are comfortable submitting bug reports, as they already have an account and are familiar with how the platform works (due to network effects.) Projects which host code on github but chose not to take bug reports there are effectively gate keeping bug submission, by asking their users to jump through the hoops of finding the site, signing up for it, and learning to use a new interface. I've done this before, with Bugzilla and Firefox, to submit a bug report for an accessibility bug on MacOS and it was a pain in the ass that I put off for a long time before becoming annoyed enough to go through the process. (End result: the bug was confirmed but never fixed..)
That said, there are also other teams and projects who do use GitHub for issue tracking. However the closer to Firefox/Gecko you are the harder this gets. For example it's hard to cross-reference GitHub issues with Bugzilla issues, or vice versa. I've seen people try to build two-way sync between GitHub and Bugzilla, but there are quite considerable technical challenges in trying to make that kind of cross-system replication work well.
However your point that GitHub makes issue submission easier for people who aren't deeply embedded in the project is a good one. I'm directly involved with webcompat.com, which aims to collect reports of broken sites from end users. It's using a GitHub issue tracker as the backend; allowing developers to directly report through GitHub, and a web-form frontend so that people without even a GitHub account can still submit reports (as you can imagine quite some effort is required here to ensure that it's not overwhelmed by spam). So finding ways to enable users to report issues is something we care about.
However, even in the webcompat.com case where collecting issues from people outside the project is the most important concern, we've taken to moving confirmed reports into bugzilla, so that they can be cross-referenced with the corresponding platform bugs, more easily used as inputs to prioritization, etc. That single source of truth for all bugs turns out to be very useful for process reasons as well as technical ones.
So — (again) without being any kind of decision maker here — I think it's very unlikely that Firefox will move entirely to GitHub issues in the foreseeable future; it's just too challenging given the history and requirements. Having some kind of one-way sync from GitHub to Bugzilla seems like a more tractable approach from an engineering point of view, but even there it's likely that there are non-trivial costs and tradeoffs involved.
> are effectively gate keeping bug submission
Of course this could be a benefit… Have you seen the quality of bug reports coming from some people, even other devs? :-)
It's really not that hard to sort through user bug reports, find and categorize the ones that are actionable and respond with boilerplate requests for more information to the rest. It's not super enjoyable, it's work, but it's absolutely manageable and devs need to keep some perspective when they complain about it. I think maybe a mandatory part of every CS education should be an internship in messy and difficult manual labor so that devs have some real context about what it means for a job to be unpleasant.
GitHub issues is terrible compared to Mozilla's Bugzilla instance. It's not even close.
I think you can dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.
Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.
I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches.
So yeah, there's that.
It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.
(aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)
There's no easy solution. Much like the recent curl security kerfuffle, the signal:noise ratio is important and hard to maintain.
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.
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 ).
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.
For projects that I'd be interested in being a long-term contributor to, this is obviously different, but you don't become a long-term contributor without first dealing with the short-term, and if you make that experience a pain, I'm unlikely to stick around.
A big part of this is the friction in signing up; I hope federated forges become more of a thing, and I can carry my identity around and start using alternate forges without having to store yet another password in my password manager.
"Friction in signing up" being a big part for you is also weird, considering basically all free software GitHub alternatives (Gitea, GitLab, Forgejo) support SSO via GitHub.
Contributors who can't use GitHub because either 1) they are fresh and can't activate a new account 2) their old grandfathered account is no longer usable or 3) their old account id doxxed and they can no longer safely contribute under the old identity.
Once you trigger phone-number verification requirement your account is globally shadowbanned and support blocked pending SMS code verification. Aside from the privacy issue it's completely blocking people in countries to which GitHub won't even try to SMS/call.
Remember that registering a second account would be violating GitHub ToS.
Not to mention the AI-generated security "issues" that are reported against curl, for example, suggests there can indeed be negative value for reports, and contributions.
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
A lot more contributions on GH, but the majority of them ignored guidelines and/or had low code quality and attention to detail. Just my anecdotal experience of course.
* contributors need to start somewhere, so even broken PRs can lead to having a valuable contributor if you're able to guide them.
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.
no.
Somehow I think you're holding the difficulty scale backwards!
I struggled to understand how the two interacted with each other, and I didn't know how to 'update my branch/pr' and I eventually just gave up.
* "the Open Source Project does not, and does not seek to, generate profit from the sale or licensing of the Open Source Software to which the Open Source Project relates, or the sale of any services related to such Open Source Software;"
* "The Open Source Project agrees not to (nor to authorize any third party to): ... (b) modify or create any derivative works of the GitLab Software ... (d) copy ... the GitLab Software"
That last part is especially problematic for everyone: in order to use GitLab.com for a FOSS project you have to renounce your right to modify (or authorize others to modify) or to copy the FOSS version of GitLab. This might have just been lawyers adding boilerplate without thinking it through, but that in itself is evidence of a major problem at GitLab.
So, GitLab is out. Aside from GitLab Mozilla could have chosen maybe Codeberg, but with the entire point being to remove barriers to new contributors it makes sense to go with the option that almost all such possible contributors are already on.
[0] https://handbook.gitlab.com/handbook/legal/opensource-agreem...
Their docs was also a mess back then and made me recompile everything even if it wasnt needed.
Now, both the desktop and the mobile version will be on Github, and the "issues" will stay on Bugzilla.
This will take advantage of both GitHub's good search and source browsing and Git's familiar system.
As a former Firefox and Thunderbird contributor, I have to say that I used local search instead of trying to find something on the mozilla-central website.
Of course, when you're actively developing software, you search inside your IDE, but allowing to find things easily on the website makes it more welcoming for potential new contributors.
On the contrary, I find searchfox to be the best code navigation tool I used. It has nice cross-language navigation features (like jumping from .webidl interface definition to c++ implementation), it has always-on blame (with more features too) and despite that it's really fast and feels extremely lightweight compared to GitHub interface. I really wish I had this with more projects, and I'll be sad if it ever dies.
Then MXR got replaced by DXR, itself replaced in 2020 by Searchfox (introduced in 2016).
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.
https://github.com/torvalds/linux
// EDIT: Source: https://news.ycombinator.com/item?id=43970574
https://github.com/mozilla-firefox/firefox/blob/main/.github...
I get it from GitHub’s perspective, it’s a nudge to get people to accept the core premise of ”social coding” and encouraging user pressure for mirrored projects to accept GitHub as a contribution entrypoint. I’m impressed by their successes and would attribute some of that to forced socialization practices such as not allowing PRs to be disabled. I’ve grown to dislike it and become disillusioned by GitHub over the course of a long time, but I’m in awe of how well it has worked for them.
EDIT: skimming these comments, I like how none of the top comments are talking about the bigger story here which is the move away from mercurial to git and instead everyone is focusing on github itself. This has essentially sealed hg away to obscurity forever. Do people not realise git is a program that runs on your computer and github is just a service that uses git? May be this is an old man gripe at this point but I'm surprised at the lack of technical discussion around this.
To be frank, I know of no other major project that used hg. In fact, I think firefox was how I learned about it in the first place many years ago.
I use it for visibility and ease, that's all. Otherwise I personally dislike it.
Here's a quick example: when I create a Mercurial repository Mercurial doesn't say anything, while Git yells at me that it's using "master" as its branch name but I can change it with a cryptic command. After a first commit for a file Mercurial once again doesn't say anything, while Git gives me three lines of information including the permissions for the file I just added. Editing and committing a file in Mercurial with "hg commit" yields (again) nothing, while typing "git commit" in Git let's me know that it knows there's a modification but it won't go through until I "stage my change for commit".
Now, imagine you're a new user. Mercurial just did what I asked, and it even guessed that "hg commit" should mean "commit everything that's been modified". Git, on the other hand, has yelled at me about default branch names (what's a branch?!), file permissions, and bickered about me not staging my commit (what's a stage?!!). They both did the same thing but, for a new user, Mercurial did it in a friendlier way.
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.
Unfortunately often the cleaner option is to create a separate org, which is a pain to use (e.g. you log in to each separately, even if they share the same SSO, PATs have to be authorised on each one separately, etc).
In Gitlab, you would have had one instance or org for Mozilla, and a namespace for Firefox, another one for other stuff, etc.
It's like AWS accounts vs GCP projects. Yeah, there are ways around the organisational limitations, but the UX is still leaky.
Now it has "main" and "autoland", what are they? Which one is the equivalent of mozilla-central before?
The "new" git default branch name is 'main' and 'autoland' existed before next to 'mozilla-central' and is the one where commits usually appear first.
Commits land in autoland and get backed out if they cause test failures. That's merged to main ~twice per day when CI is happy
I've mostly encountered these branches/repos when checking commits linked to Bugzilla tickets, and I don't recall seeing "autoland" show up too much in those cases.
But I think hg support is going away. We hg enthusiasts at Mozilla are mostly fleeing to Jujutsu.
On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.
Surely most open source projects have a link to their source code? Whether it's github, gitlab, sourcehut, or anything else?
But it’s a lot of work to prevent abuse, especially for resource intensive features when supporting unsigned-in use cases.
https://wiki.mozilla.org/ReleaseEngineering/DisposableProjec...
Fun to get a glimpse into someone's thought process while they were working.
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!
Bad PRs all around, with just a constant stream of drive by "why no merge?!?!?!" comments.
Even before this Mozilla almost certainly used hundreds of closed source tools, including things like Slack, Excel, Anaplan, Workday, etc.
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
They should restructure instead, hire people who actually want to work on software and not use corporation and foundation around it as platform for their... peculiar "endeavours". But I doubt that's gonna happen - flow of Google cash and from all those naive people who think supporting Mozilla directly contributes to Firefox is too good it seems. But then it's understandable they do this - money from Google tap can get twisted.
Think you might be on something, with the incoming end of Google cash flow, Firefox may be in discussion with bing and that could be part of the agreement, use Microsoft server.
issues are stored in git bug and automatically synced. Github is the only viable option, but you can keep the others as mirrors when github chooses to strike you.
Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
There is https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge.
Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs
The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled.
https://github.com/git-bug/git-bug/blob/master/doc/usage/thi...
I have not tried it.
You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository.
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Radicle offers one. CLI-based, too.
And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem.
I don't need to know how a filesystem works internally to be able to use it.
And having a centralized store and history helps a lot to keep a version control system conceptually simple.
The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.
If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.
You might like git-bug:
This should be one of the very first links in the readme.
Embrace, Extend..
(largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).
You can also quite easily set up a temporary remote (this can be as simple a directory on an SSH server), or if you're on the same local network, pull and push directly from each others' local copies.
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.
For the actual event we are commenting on, they have disabled all features other than code hosting and PRs.
Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.
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!
If you weren't connected to the internet, you couldn't do a thing. You couldn't checkout. You couldn't commit. You could create branches. The only thing on your computer was whatever you checked out last time you were connected to the server.
People talk about SVN, but it wasn't that common in 2005. None of the project hosting platforms (like SourceForge) supported SVN, they were all still offering CVS. If you wanted to use SVN, you had to set it up on your own server. (From memory, google code was the first to offer SVN project hosting in mid-2006). Not that SVN was much better than CVS. It was more polished, but shared all the same workflow flaws.
Before Git (and friends), nothing like pull-requests existed. If you wanted to collaborate with someone else, you either gave them an account on your CVS/SVN server (and then they could create a branch and commit their code), or they sent you patch files over email.
The informal email pull requests of git were an improvement... though you still needed to put your git repo somewhere public. Github and its web-based pull requests were absolutely genius. Click a button, fork the project, branch, hack, commit, push, and then create a formal "pull request". It was nothing like centralised project management systems before it. A complete breath of fresh air.
And it was actually part of git. Even back in 2005, git included a script git request pull that generated these pull request emails. I'm pretty sure people called these emails "pull requests" before GitHub came along.
2006 appears to be the year that SVN finally became somewhat mainstream, which is interesting because git was released in 2005. Github launched in 2008 and by 2009, everyone seemed to be abandoning SVN.
It feels like SVN was only really "mainstream" for about 3 years, Maybe 5 years at most; There was some early-adopter lead-up and then a long tail of repos refusing to switch to git.
Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email etc.)
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.
Didn't all this start with Linus getting into a spat with the bitkeeper dev involving some sort of punitive measure as a response to somebody making a reverse-engineered FOSS client? I don't remember the details and I'm sure I have at least half of them wrong, but that's easily one of the most disastrous decisions in the history of the software-business right up there with valve turning down minecraft and EA refusing to make sports games for the SEGA dreamcast (that last one isn't as well known but it led to SEGA launching the 2k sports brand to which outlasted the dreamcast and eventually got sold to a different company but otherwise still exists today and is still kicking EA's ass on basketball games).
But there were already quite a handful of other distributed version control systems around by the time git showed up.
So if Linus hadn't written git, perhaps we would be using darcs these days. And then we'd be debating whether people are using darcs the way it was intended. Or bazaar or monotone or mercurial etc.
I don't think what the original authors of any one tool intended matters very much, when there were multiple implementations of the idea around.
It's a joke that the bitkeeper dev has two revision control named after him, Mercurial and Git.
And while NBA 2k destroyed NBA Live it took until 2009 for that to start happening (long after Sega ownership), mainly down to sliding standards in EA’s NBA Live titles and eventually some disastrous EA launches.
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.
Everything is fully and completely explained, in terms which mean nothing.
(They ain't perfect, of course.)
If you push rewritten history to master, you're a git.
Conclusion: learn your tools.
Also, git store the files in a smarter way so file size won't explode like zip versioning.
Or previous versions. Plural. Yes.
Well, that's one half of git. The other half is tooling to work with the snapshots and their history, eg to perform merges.
In the Linux kernel the project management is done via email (which is also just a centralized webserver in the end), so whats the problem?
From what I use composer and brew relies on GitHub to work.
And: Even though source of truth is centralized for many projects in GitHub, git still benefits from being distributed: It's the basis for "forks" on VithUb and for the way people develop. Ja jung the clone locally and committing locally and preparing the change set for review. In the CVS/SVN days one had to commit to the ce teal branch way sooner and more direct.
Then later on for the PR, you can sanitise the whole thing for review.
In the bad old days, you only got the latter. (Unless you manually set up an unrelated repository for the former yourself.)
I am contributing to a few open source projects on GitHub here and there though.
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.
People who are very insistent on distributed solutions never seem to understand that the economic, social and organizational reasons for division of labor, hierarchy and centralization didn't suddenly go away.
It's not like the hairy C++ code base of Firefox will suddenly become less scary and attract more open source developers simply because it's moving to Github.
I store my code in a completely distributed fashion, often in several places on different local devices (laptop, build server, backup, etc) not to mention on remote systems. I use github and gitlab for backup and distribution purposes, as well as alternative ways people can share code with me (other than sending patch emails), and other people use git to get and collaborate on my work.
distributed version control system doesn't mean distributed storage magically happens. You still need to store your code on storage you trust at some level. The distributed in DVCS means that collaboration and change management is distributed. All version control operations can be performed on your own copy of a tree with no other involvement. Person A can collaborate with person B, then person B can collaborate with person C without person A being in the loop, etc.
Gitorious was chosen for the meego/maemo team for example.
And I am one of the people saddened by the convergence on a single platform.
But you can't deny, it's always been pretty great.
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.
Sure, there would be local copies everywhere, but 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?
It wont be free software and, likely, it will be Microsoft.
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.
The bad news is that their build system is extremely hand-rolled, and so if it works for you, count yourself lucky, because when it doesn't work you're in for 4 hours of python hell
The killer feature is collocation of features to a single forge, combined with a generous free tier it’s the windows xp of the ecosystem: everybody has it, everybody knows it, almost nobody knows anything else.
As for PRs: I'm sure Mozilla welcome contributions, but accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage.
I agree it is rather basic but I don't see how it's hard to navigate.
> accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage.
I don't think that really happens based on what I've seen of other huge projects on GitHub.
Jira and bugzilla are vastly superior to GH Issues.
Jira doesn't even deserve 10% of the hate it gets. Most of what makes Jira awful is the people using it. Bugzilla is getting a bit long in the tooth, but at least it's still free and open source.
mozilla-central has a LOT of tests -- each push burns a lot of compute hours.
Some associated projects are using more GitHub stuff.
I was thinking something different: I wonder whether Mozilla considered GitLab or Codeberg, which are the other two I know that are popular with open source projects that don't trust GitHub since it sold out to Microsoft.
(FWIW, Microsoft has been relatively gentle or subtle with GitHub, for whatever reason. Though presumably MS will backstab eventually. And you can debate whether that's already started, such as with pushing "AI" that launders open source software copyrights, and offering to indemnify users for violations. But I'd guess that a project would be pragmatically fine at least near term going with GitHub, though they're not setting a great example.)
"It depends", as always, but codeberg lacks features (that your use-case may not need, or may require), uptime/performance (that may be crucial or inconsequential to your use-case), familiarity (that may deter devs), integration (that may be time-consuming to build yourself or be unnessecary for your case) etc etc.
It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.
