I’ve interacted with the LLVM project only once (an attempt to add a new clang diagnostic), and my experience with Phabricator was a bit painful (in particular, the arcanist tool). Switching to GitHub will certainly reduce friction for (new) contributors.
However, it’s dismaying to see GitHub capture even more critical software infrastructure. LLVM is a huge and enormously impactful project. GitHub has many eggs in their basket. The centralization of so much of the software engineering industry into a single mega-corp-owned entity makes me more than a little uneasy.
There are so many alternatives they could have chosen if they wanted the pull/merge request model. It really is a shame they ended up where they did. I’d love to delete my Microsoft GitHub account just like I deleted my Microsoft LinkedIn account, but the lock-ins all of these projects takes means to participate in open source, I need to keep a proprietary account training on all of our data, upselling things we don’t need, & making a code forge a social media platform with reactions + green graphs to induce anxiety + READMEs you can’t read anymore since it’s all about marketing (inside their GUI) + Sponsors which should be good but they’re skimming their cut of course + etc..
It really is a shame they ended up where they did.
If even 1% of the energy that’s spent on shaming and scolding open-source maintainers for picking the “wrong” infrastructure was instead diverted into making the “right” infrastructure better, this would not be a problem.
Have you used them? They’re all pretty feature complete. The only difference really is alternatives aren’t a social network like Microsoft GitHub & don’t have network effect.
It’s the same with chat apps—they can all send messages, voice/video/images, replies/threads. There’s no reason to be stuck with WhatsApp, Messenger, Telegram, but people do since their network is there. So you need to get the network to move.
The only difference really is alternatives aren’t a social network like Microsoft GitHub & don’t have network effect.
And open-source collaboration is, in fact, a social activity. Thus suggests an area where alternatives need to be focusing some time and effort, rather than (again) scolding and shaming already-overworked maintainers who are simply going where the collaborators are.
Breaking out the word “social” from “social media” isn’t even talking about the same thing. It’s social network ala Facebook/Twitter with folks focusing on how many stars, how green their activity bars are, how flashy their RENDERME.md file is, scrolling feeds, avatars, Explore—all to keep you on the platform. And as a result you can hear anxiety in many developers on how their Microsoft GitHub profile looks—as much as you hear folks obsessing about their TikTok or Instagram comments. That social anxiety should have little place in software.
Microsoft GitHub’s collaboration system isn’t special & doesn’t even offer a basic feature like threading, replying to a inline-code comment via email puts a new reply on the whole merit request, and there are other bugs. For collaboration, almost all of alternatives have a ticketing system, with some having Kanban, & additional features—but even then, a dedicated (hopefully integrated) ticketing system, forum, mailing list, or libre chat option can offer a better, tailored experience.
Suggesting open source dogfood on open source leads to better open source & more contributions rather than allowing profit-driven entities to try to gobble up the space. In the case of these closed platforms you as a maintainer are blocking off an entire part of your community that values privacy/freedom or those blocked by sanctions while helping centralization. The alternatives are in the good-to-good-enough category so there’s nothing to lose and opens up collaboration to a larger audience.
But I’ll leave you with a quote
Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority.
In the case of these closed platforms you as a maintainer are blocking off an entire part of your community that values privacy/freedom or those blocked by sanctions while helping centralization.
The population of potential collaborators who self-select out of GitHub for “privacy/freedom”, or “those blocked by sanctions”, is far smaller than the population who actually are on GitHub. So if your goal is to make an appeal based on size of community, be aware that GitHub wins in approximately the same way that the sun outshines a candle.
And even in decentralized protocols, centralization onto one, or at most a few, hosts is a pretty much inevitable result of social forces. We see the same thing right now with federated/decentralized social media – a few big instances are picking up basically all the users.
But I’ll leave you with a quote
There is no number of quotes that will change the status quo. You could supply one hundred million billion trillion quadrillion octillion duodecillion vigintillion Stallman-esque lectures per femtosecond about the obvious moral superiority of your preference, and win over zero users in doing so. In fact, the more you moralize and scold the less likely you are to win over anyone.
If you genuinely want your preferred type of code host to win, you will have to, sooner or later, grapple with the fact that your strategy is not just wrong, but fundamentally does not grasp why your preferences lost.
Some folks do have a sense of morality to the decisions they make. There are always trade offs, but I fundamentally do not agree that the tradeoffs for Microsoft GitHub outweigh the issue of using it. Following the crowd is less something I’m interested in than being the change I & others would like to see. Sometimes I have ran into maintainers who would like to switch but are afraid of if folks would follow them & are then reassured that the project & collaboration will continue. I see a lot of positive collaboration on SourceHut ‘despite’ not having the social features and doing collaboration via email + IRC & it’s really cool. It’s possible to overthrow the status quo—and if the status quo is controlled by a US megacorp, yeah, let’s see that change.
Sometimes I have ran into maintainers who would like to switch but are afraid of if folks would follow them & are then reassured that the project & collaboration will continue.
But this is a misleading statement at best. Suppose that on Platform A there are one million active collaborators, and on Platform B there are ten. Sure, technically “collaboration will continue” if a project moves to Platform B, but it will be massively reduced by doing so.
And many projects simply cannot afford that. So, again, your approach is going to fail to convert people to your preferred platforms.
I don’t see caring about user privacy/freedoms & shunning corporate control as merely a preference like choosing a flavor of jam at the market. And if folks aren’t voicing an opinion, then the status quo would remain.
the social network part is more harmful than good.
I think you underestimate the extent to which social features get and keep people engaged, and that the general refusal of alternatives to embrace the social nature of software development is a major reason why they fail to “convert” people from existing popular options like GitHub.
To clarify, are you saying that social gamification features like stars and colored activity bars are part of the “social nature of software development” which must be embraced?
Assuming they wanted to move specifically to Git & not a different DVCS, LLVM probably would have the resources to run a self-hosted Forgejo instance (what ‘powers’ Codeberg). Forgejo supports that pull/merge request model—and they are working on the ForgeFed protocol which would as a bonus allow federation support which means folks wouldn’t even have to create an account to open issues & participate in merge requests which is a common criticism of these platforms (i.e. moving from closed, proprietary, megacorp Microsoft GitHub to open-core, publicly-traded, VC-funded GitLab is in many ways a lateral move at the present even if self-hosted since an account is still required). If pull/merge request + Git isn’t a requirement, there are more options.
(i.e. moving from closed, proprietary, megacorp Microsoft GitHub to open-core, publicly-traded, VC-funded GitLab is in many ways a lateral move at the present even if self-hosted since an account is still required)
How do they manage to require you to make an account for self-hosted GitLab? Is there a fork that removes that requirement?
Self-hosting GitLab does not require any connection to GitLab computers. There is no need to create an account at GitLab to use a self-hosted GitLab instance. I’ve no idea where this assertion comes from.
One does need an account to contribute on a GitLab instance. There is integration with authentication services.
Alternatively, one could wait for the federated protocol.
In my personal, GitHub-avoiding, experience, I’ve found that using mail to contribute usually works.
One does need an account to contribute on a GitLab instance.
That’s what I meant… account required for the instance. With ForgeFed & mailing lists, no account on the instance is required. But news 1–2 weeks ago was trying to get some form of federation to GitLab. It was likely a complaint about needing to create accounts on all of the self-hosted options.
However, it’s dismaying to see GitHub capture even more critical software infrastructure. LLVM is a huge and enormously impactful project. GitHub has many eggs in their basket. The centralization of so much of the software engineering industry into a single mega-corp-owned entity makes me more than a little uneasy.
I think the core thing is that projects aren’t in the “maintain a forge” business, but the “develop a software project” business. Self-hosting is not something they want to be doing, as you can see by the maintenance tasks mentioned the article.
Of course, then the question is, why GitHub instead of some other managed service? It might be network effect, but honestly, it’s probably because it actually works mostly pretty well - that’s how it grew without a network effect in the first place. (Especially on a UX level. I did not like having to deal with Phabricator and Gerrit last time I worked with a project using those.)
I would not be surprised if GitHub actively courted them as hostees. It’s a big feather in GH’s cap and reinforces the idea that GH == open source development.
I think the move started on our side, but GitHub was incredibly supportive. They added a couple of new features that were deal breakers and they waived the repo size limits.
There is Codeberg & others running Forgejo/Gitea as well as SourceHut & GitLab which are all Git options without needing Microsoft GitHub or self-hosting. There are others for non-Git DVCSs. The Microsoft GitHub UI is slow, breaks all my browser shortcuts, and has upsell ads all throughout. We aren’t limited to if not MicrosoftGitHub then SelfHost.
To me, Phabricator’s workflow embodies several important things:
First is that it’s amend- and rebase-oriented. It is so awful to open a GitHub PR and see it spammed full of “fix typo”-like micro commits. Either all of those are going to be applied to the main branch and spam it up, or the committer is going to blindly squash them all into one, even if the changes would have been clearer in two or three thoughtfully structured commits. Tangentially related is that applying contributions by Merge leads to useless and noisy “Merge pull request X from Y” commits in the log. I have no idea why GitHub chose the merge workflow as the default.
The above paragraph applies to mailing-list patch workflow as well, which is why I prefer it to GitHub’s workflow.
Phabricator has one additionally important distinguishing factor that really makes it great. It’s a simple one: the unit of review is one commit. Not a patchset, like in mailing list patch workflow, not an entire branch, like in GitHub workflow. You submit individual Revisions (DXXXXX) which are basically just patch files, but you can stack them on top of each other to declare a dependency order. Updates are tracked instead of having to force push and lose context on GitHub.
This has the great effect of “right-sizing” the unit of review and of the commits. And what it leads to is that when you look back at your commit history, you have a very, very neatly groomed log of commits that form a cohesive story about the code. No useless merge commits, no useless spam from typos, no monster PR’s squashed into one massive commit. Just a clean history.
Phabricator is basically what you get when you take the best of the mailing list patch workflow and follow it to its conclusion.
It’s hard for me to explain to people who have only ever used GitHub why the default setup sucks. I’d say about 25% of the reason why I still work at Facebook is because the code review and submission tools are just that good (they have advanced significantly even further beyond open source Phabricator)
And all of that still hasn’t touched on why having a single monopoly host critical open source projects is a problem, automation issues with the loss of Herald rules, etc.
I have never used Phabricator but I was lucky enough to use Gerrit at a previous job, which was the first (and so far only) code review tool I’ve used that isn’t significantly worse than a mailing list. Have you ever used Gerrit? Are you able to compare it to Phabricator? From your description, they sound similar.
Problems with Pull Requests and How to Fix Them is really great and I linked to it in the article. It made me more firmly believe GitHub pull requests are fundamentally flawed…
I haven’t used Gerrit before, but I wouldn’t be surprised if it was mostly similar to Phabricator, given how similar Google and Facebook tooling tends to be.
I find it depressing that we’re stuck on Github and its broken PR model because the industry must cater for a ‘lowest common denominator’ type of developer.
Fairly recently, GitHub has made it possible to update the target branch for PRs, and, if a PR is merged it will up automatically update PRs that merged into that branch to merge to the branch it merged into. This lets you do stacked reviews, kind of.
There is precisely one feature that I miss in Azure DevOps: proper fast-forward merges of PRs. GitHub can’t do this because it rewrites the commit message to include the PR metadata, I think ADO stores PR merge commits as tags. This makes it painful to use submodules because you can’t have a PR that updates a submodule to a PR in another repo without it breaking as soon as the upstream one is merged.
It’s a nice hack, but that means that any time someone wants something reviewed separately, they have to make a new branch. It’s at odds with what I mentioned above regarding “the unit of review is the commit”, and its right-sizing effect on contributions.
This is really unfortunate. GitHub already is too big and hosts too many important projects. I understand they want to “catch” casual committers, which is easier to do on GitHub, but overall the points of view were pretty divided in the original discussion about it:
The fact that GitLab wasn’t considered (or I’ve missed it) suggest to me that it wasn’t about Phabricator having a “bad” workflow that needed fixing, but rather it was about the site.
Yes, but how many “casual commiters” are going to contribute to somehting like LLVM? Even less for code review access? I would have thought, casuals might maybe look at pull requests, but why’d they want to contribute?
Sending email patches still is pretty fragile (i.e. did my mail client mess it up?), and I’m already signed into GitHub anyways. Hitting “fork” and pushing a branch isn’t a big deal compared to having to babysit mail and deal with a mail based review process.
Hell, I’ve just dumped diffs on an issue tracker before (GitHub’s included), and I’ll still take that over email.
You’re still forced to participate and use a closed and proprietary platform, no matter how much they claim to love open source. Though I guess this gets more into the political side of this decision than the technical aspects.
I’d guess the logic is that there are more people who will start contributing because it’s convenient and familiar than people who will stop contributing because it’s proprietary. Sometimes you just gotta be pragmatic.
I should check the site and my notifications more often, this comes 3 days late.
On topic: with my question about casual commiters, I asked about it because I don’t know if I would ever just “drive-by-contribute” to something like LLVM. I may be tempted to open an issue, but LLVM is a very hard niche. I’m probably wrong, but my expectation is that only a tiny, tiny fraction of people using LLVM will ever look at its source code. And those who actually do, they would not be stopped by creating an account - from my personal experience, I’d be more likely to trust them since they’re running on their own platform. They’re a big project, they deserve it.
I hadn’t considered just casual readers. My question still stands. If I read a random article - say, linked from Lobsters - I may land on the LLVM repo, I may browse around the code a bit. For just “drive-by-reading” I don’t care if it’s github or not.
I’m not saying the reasoning is correct or incorrect, I am just saying that the question of “casual commiters” seems pretty moot, and that @dark_grimoire’s comment that it’s not about the workflow or contributors, but rather about the site, makes a lot of sense.
Yes, although I think Phacility announced EOL of Phabricator in 2021, and the discussions about LLVM switching to GitHub seems to have started in 2019. Another thing is that Phabricator is now continued as Phorge.
I only occasionally have to use GitHub PRs but I find them truly awful. At a basic level I couldn’t work out how to sanely write a series of dependent changes that I needed to land independently. It’s very straight-forward for me to have multiple branches that have multiple patch series with gerrit based projects I contribute to. FWIW when I recently used LLVM’s phabricator after not having used Phabricator for over a decade I found it straightforward, at least compared to the mess of GitHub PRs.
GitHub, however, is less flexible in this regard. Individual users can choose to watch all pull requests, but they can’t do so selectively.
For anyone who wants to watch issues, but limit the flood, my app https://www.CodeTriage.com sends you N random open issues per along with automatic back off of emails if you get worn out.
It’s still not total control, but it’s a middle ground between all or nothing.
If only this could convince GitHub to make their code review tool more similar to Gerrit (especially when it comes to reviewing and updating a series of dependent changes).
Asking this audience before I do any research: Is there a local code review tool that can layer on top of git and the GitHub pull request API to restore some of the lost productivity for reviewers? Wondering if one could have the ease of contribution of GitHub without suffering the limitations of the GitHub review experience.
Is there a local code review tool that can layer on top of git and the GitHub pull request API to restore some of the lost productivity for reviewers?
Facebook’s Sapling (internal fork of Mercurial) has an extension called ReviewStack1 that shoehorns the stacked-diff workflow onto GitHub PR’s, so that part can be papered over. The part about Herald rules has no valid replacement besides each person doing their own email filtering.
I’ve interacted with the LLVM project only once (an attempt to add a new clang diagnostic), and my experience with Phabricator was a bit painful (in particular, the arcanist tool). Switching to GitHub will certainly reduce friction for (new) contributors.
However, it’s dismaying to see GitHub capture even more critical software infrastructure. LLVM is a huge and enormously impactful project. GitHub has many eggs in their basket. The centralization of so much of the software engineering industry into a single mega-corp-owned entity makes me more than a little uneasy.
There are so many alternatives they could have chosen if they wanted the pull/merge request model. It really is a shame they ended up where they did. I’d love to delete my Microsoft GitHub account just like I deleted my Microsoft LinkedIn account, but the lock-ins all of these projects takes means to participate in open source, I need to keep a proprietary account training on all of our data, upselling things we don’t need, & making a code forge a social media platform with reactions + green graphs to induce anxiety + READMEs you can’t read anymore since it’s all about marketing (inside their GUI) + Sponsors which should be good but they’re skimming their cut of course + etc..
If even 1% of the energy that’s spent on shaming and scolding open-source maintainers for picking the “wrong” infrastructure was instead diverted into making the “right” infrastructure better, this would not be a problem.
Have you used them? They’re all pretty feature complete. The only difference really is alternatives aren’t a social network like Microsoft GitHub & don’t have network effect.
It’s the same with chat apps—they can all send messages, voice/video/images, replies/threads. There’s no reason to be stuck with WhatsApp, Messenger, Telegram, but people do since their network is there. So you need to get the network to move.
And open-source collaboration is, in fact, a social activity. Thus suggests an area where alternatives need to be focusing some time and effort, rather than (again) scolding and shaming already-overworked maintainers who are simply going where the collaborators are.
Breaking out the word “social” from “social media” isn’t even talking about the same thing. It’s social network ala Facebook/Twitter with folks focusing on how many stars, how green their activity bars are, how flashy their RENDERME.md file is, scrolling feeds, avatars, Explore—all to keep you on the platform. And as a result you can hear anxiety in many developers on how their Microsoft GitHub profile looks—as much as you hear folks obsessing about their TikTok or Instagram comments. That social anxiety should have little place in software.
Microsoft GitHub’s collaboration system isn’t special & doesn’t even offer a basic feature like threading, replying to a inline-code comment via email puts a new reply on the whole merit request, and there are other bugs. For collaboration, almost all of alternatives have a ticketing system, with some having Kanban, & additional features—but even then, a dedicated (hopefully integrated) ticketing system, forum, mailing list, or libre chat option can offer a better, tailored experience.
Suggesting open source dogfood on open source leads to better open source & more contributions rather than allowing profit-driven entities to try to gobble up the space. In the case of these closed platforms you as a maintainer are blocking off an entire part of your community that values privacy/freedom or those blocked by sanctions while helping centralization. The alternatives are in the good-to-good-enough category so there’s nothing to lose and opens up collaboration to a larger audience.
But I’ll leave you with a quote
— Matt Lee, https://www.linuxjournal.com/content/opinion-github-vs-gitlab
The population of potential collaborators who self-select out of GitHub for “privacy/freedom”, or “those blocked by sanctions”, is far smaller than the population who actually are on GitHub. So if your goal is to make an appeal based on size of community, be aware that GitHub wins in approximately the same way that the sun outshines a candle.
And even in decentralized protocols, centralization onto one, or at most a few, hosts is a pretty much inevitable result of social forces. We see the same thing right now with federated/decentralized social media – a few big instances are picking up basically all the users.
There is no number of quotes that will change the status quo. You could supply one hundred million billion trillion quadrillion octillion duodecillion vigintillion Stallman-esque lectures per femtosecond about the obvious moral superiority of your preference, and win over zero users in doing so. In fact, the more you moralize and scold the less likely you are to win over anyone.
If you genuinely want your preferred type of code host to win, you will have to, sooner or later, grapple with the fact that your strategy is not just wrong, but fundamentally does not grasp why your preferences lost.
Some folks do have a sense of morality to the decisions they make. There are always trade offs, but I fundamentally do not agree that the tradeoffs for Microsoft GitHub outweigh the issue of using it. Following the crowd is less something I’m interested in than being the change I & others would like to see. Sometimes I have ran into maintainers who would like to switch but are afraid of if folks would follow them & are then reassured that the project & collaboration will continue. I see a lot of positive collaboration on SourceHut ‘despite’ not having the social features and doing collaboration via email + IRC & it’s really cool. It’s possible to overthrow the status quo—and if the status quo is controlled by a US megacorp, yeah, let’s see that change.
But this is a misleading statement at best. Suppose that on Platform A there are one million active collaborators, and on Platform B there are ten. Sure, technically “collaboration will continue” if a project moves to Platform B, but it will be massively reduced by doing so.
And many projects simply cannot afford that. So, again, your approach is going to fail to convert people to your preferred platforms.
I don’t see caring about user privacy/freedoms & shunning corporate control as merely a preference like choosing a flavor of jam at the market. And if folks aren’t voicing an opinion, then the status quo would remain.
You seem to see it as a stark binary where you either have it or you don’t. Most people view it as a spectrum on which they make tradeoffs.
Already mentioned it. This case is a clear ‘not worth it’ because the alternatives are sufficient & the social network part is more harmful than good.
I think you underestimate the extent to which social features get and keep people engaged, and that the general refusal of alternatives to embrace the social nature of software development is a major reason why they fail to “convert” people from existing popular options like GitHub.
To clarify, are you saying that social gamification features like stars and colored activity bars are part of the “social nature of software development” which must be embraced?
Would you clarify?
And yet here you are, shaming and scolding.
What alternatives do you have in mind?
Assuming they wanted to move specifically to Git & not a different DVCS, LLVM probably would have the resources to run a self-hosted Forgejo instance (what ‘powers’ Codeberg). Forgejo supports that pull/merge request model—and they are working on the ForgeFed protocol which would as a bonus allow federation support which means folks wouldn’t even have to create an account to open issues & participate in merge requests which is a common criticism of these platforms (i.e. moving from closed, proprietary, megacorp Microsoft GitHub to open-core, publicly-traded, VC-funded GitLab is in many ways a lateral move at the present even if self-hosted since an account is still required). If pull/merge request + Git isn’t a requirement, there are more options.
How do they manage to require you to make an account for self-hosted GitLab? Is there a fork that removes that requirement?
Self-hosting GitLab does not require any connection to GitLab computers. There is no need to create an account at GitLab to use a self-hosted GitLab instance. I’ve no idea where this assertion comes from.
One does need an account to contribute on a GitLab instance. There is integration with authentication services.
Alternatively, one could wait for the federated protocol.
In my personal, GitHub-avoiding, experience, I’ve found that using mail to contribute usually works.
That’s what I meant… account required for the instance. With ForgeFed & mailing lists, no account on the instance is required. But news 1–2 weeks ago was trying to get some form of federation to GitLab. It was likely a complaint about needing to create accounts on all of the self-hosted options.
I think the core thing is that projects aren’t in the “maintain a forge” business, but the “develop a software project” business. Self-hosting is not something they want to be doing, as you can see by the maintenance tasks mentioned the article.
Of course, then the question is, why GitHub instead of some other managed service? It might be network effect, but honestly, it’s probably because it actually works mostly pretty well - that’s how it grew without a network effect in the first place. (Especially on a UX level. I did not like having to deal with Phabricator and Gerrit last time I worked with a project using those.)
I would not be surprised if GitHub actively courted them as hostees. It’s a big feather in GH’s cap and reinforces the idea that GH == open source development.
I think the move started on our side, but GitHub was incredibly supportive. They added a couple of new features that were deal breakers and they waived the repo size limits.
There is Codeberg & others running Forgejo/Gitea as well as SourceHut & GitLab which are all Git options without needing Microsoft GitHub or self-hosting. There are others for non-Git DVCSs. The Microsoft GitHub UI is slow, breaks all my browser shortcuts, and has upsell ads all throughout. We aren’t limited to
if not MicrosoftGitHub then SelfHost.This is literally what I addressed in the second paragraph of my comment.
Not arguing against you, but with you showing examples.
To me, Phabricator’s workflow embodies several important things:
First is that it’s amend- and rebase-oriented. It is so awful to open a GitHub PR and see it spammed full of “fix typo”-like micro commits. Either all of those are going to be applied to the main branch and spam it up, or the committer is going to blindly squash them all into one, even if the changes would have been clearer in two or three thoughtfully structured commits. Tangentially related is that applying contributions by Merge leads to useless and noisy “Merge pull request X from Y” commits in the log. I have no idea why GitHub chose the merge workflow as the default.
The above paragraph applies to mailing-list patch workflow as well, which is why I prefer it to GitHub’s workflow.
Phabricator has one additionally important distinguishing factor that really makes it great. It’s a simple one: the unit of review is one commit. Not a patchset, like in mailing list patch workflow, not an entire branch, like in GitHub workflow. You submit individual Revisions (DXXXXX) which are basically just patch files, but you can stack them on top of each other to declare a dependency order. Updates are tracked instead of having to force push and lose context on GitHub. This has the great effect of “right-sizing” the unit of review and of the commits. And what it leads to is that when you look back at your commit history, you have a very, very neatly groomed log of commits that form a cohesive story about the code. No useless merge commits, no useless spam from typos, no monster PR’s squashed into one massive commit. Just a clean history.
Phabricator is basically what you get when you take the best of the mailing list patch workflow and follow it to its conclusion.
It’s hard for me to explain to people who have only ever used GitHub why the default setup sucks. I’d say about 25% of the reason why I still work at Facebook is because the code review and submission tools are just that good (they have advanced significantly even further beyond open source Phabricator)
And all of that still hasn’t touched on why having a single monopoly host critical open source projects is a problem, automation issues with the loss of Herald rules, etc.
I have never used Phabricator but I was lucky enough to use Gerrit at a previous job, which was the first (and so far only) code review tool I’ve used that isn’t significantly worse than a mailing list. Have you ever used Gerrit? Are you able to compare it to Phabricator? From your description, they sound similar.
Edit: I just found Problems with Pull Requests and How to Fix Them
Problems with Pull Requests and How to Fix Them is really great and I linked to it in the article. It made me more firmly believe GitHub pull requests are fundamentally flawed…
I haven’t used Gerrit before, but I wouldn’t be surprised if it was mostly similar to Phabricator, given how similar Google and Facebook tooling tends to be.
I find it depressing that we’re stuck on Github and its broken PR model because the industry must cater for a ‘lowest common denominator’ type of developer.
Fairly recently, GitHub has made it possible to update the target branch for PRs, and, if a PR is merged it will up automatically update PRs that merged into that branch to merge to the branch it merged into. This lets you do stacked reviews, kind of.
There is precisely one feature that I miss in Azure DevOps: proper fast-forward merges of PRs. GitHub can’t do this because it rewrites the commit message to include the PR metadata, I think ADO stores PR merge commits as tags. This makes it painful to use submodules because you can’t have a PR that updates a submodule to a PR in another repo without it breaking as soon as the upstream one is merged.
It’s a nice hack, but that means that any time someone wants something reviewed separately, they have to make a new branch. It’s at odds with what I mentioned above regarding “the unit of review is the commit”, and its right-sizing effect on contributions.
This is really unfortunate. GitHub already is too big and hosts too many important projects. I understand they want to “catch” casual committers, which is easier to do on GitHub, but overall the points of view were pretty divided in the original discussion about it:
https://lists.llvm.org/pipermail/llvm-dev/2019-November/136579.html
The fact that GitLab wasn’t considered (or I’ve missed it) suggest to me that it wasn’t about Phabricator having a “bad” workflow that needed fixing, but rather it was about the site.
Yes, but how many “casual commiters” are going to contribute to somehting like LLVM? Even less for code review access? I would have thought, casuals might maybe look at pull requests, but why’d they want to contribute?
“Casual” in this context implies “drive-by contributor”. Being on GH and being able to quickly file a PR for a patch is convenient in that regard.
Mailing lists remain the best drive-by workflow, it’s just that the educational resources are poor for it (git-send-email.io has helped).
Clone -> make commits -> git-send-email
No need to make a “fork”. No need to sign into or even visit a proprietary platform.
Sending email patches still is pretty fragile (i.e. did my mail client mess it up?), and I’m already signed into GitHub anyways. Hitting “fork” and pushing a branch isn’t a big deal compared to having to babysit mail and deal with a mail based review process.
Hell, I’ve just dumped diffs on an issue tracker before (GitHub’s included), and I’ll still take that over email.
You’re still forced to participate and use a closed and proprietary platform, no matter how much they claim to love open source. Though I guess this gets more into the political side of this decision than the technical aspects.
I’d guess the logic is that there are more people who will start contributing because it’s convenient and familiar than people who will stop contributing because it’s proprietary. Sometimes you just gotta be pragmatic.
I should check the site and my notifications more often, this comes 3 days late.
On topic: with my question about casual commiters, I asked about it because I don’t know if I would ever just “drive-by-contribute” to something like LLVM. I may be tempted to open an issue, but LLVM is a very hard niche. I’m probably wrong, but my expectation is that only a tiny, tiny fraction of people using LLVM will ever look at its source code. And those who actually do, they would not be stopped by creating an account - from my personal experience, I’d be more likely to trust them since they’re running on their own platform. They’re a big project, they deserve it.
I hadn’t considered just casual readers. My question still stands. If I read a random article - say, linked from Lobsters - I may land on the LLVM repo, I may browse around the code a bit. For just “drive-by-reading” I don’t care if it’s github or not.
I’m not saying the reasoning is correct or incorrect, I am just saying that the question of “casual commiters” seems pretty moot, and that @dark_grimoire’s comment that it’s not about the workflow or contributors, but rather about the site, makes a lot of sense.
The software is all but dead: https://github.com/phacility/phabricator/commit/9ceb66453501d461800617b9fb2d4af4ba2c9514
Yes, although I think Phacility announced EOL of Phabricator in 2021, and the discussions about LLVM switching to GitHub seems to have started in 2019. Another thing is that Phabricator is now continued as Phorge.
I only occasionally have to use GitHub PRs but I find them truly awful. At a basic level I couldn’t work out how to sanely write a series of dependent changes that I needed to land independently. It’s very straight-forward for me to have multiple branches that have multiple patch series with gerrit based projects I contribute to. FWIW when I recently used LLVM’s phabricator after not having used Phabricator for over a decade I found it straightforward, at least compared to the mess of GitHub PRs.
For anyone who wants to watch issues, but limit the flood, my app https://www.CodeTriage.com sends you N random open issues per along with automatic back off of emails if you get worn out.
It’s still not total control, but it’s a middle ground between all or nothing.
If only this could convince GitHub to make their code review tool more similar to Gerrit (especially when it comes to reviewing and updating a series of dependent changes).
Asking this audience before I do any research: Is there a local code review tool that can layer on top of git and the GitHub pull request API to restore some of the lost productivity for reviewers? Wondering if one could have the ease of contribution of GitHub without suffering the limitations of the GitHub review experience.
Facebook’s Sapling (internal fork of Mercurial) has an extension called ReviewStack1 that shoehorns the stacked-diff workflow onto GitHub PR’s, so that part can be papered over. The part about Herald rules has no valid replacement besides each person doing their own email filtering.
Compare also, my experience trying to contribute small fixes to LLVM before the switch to github
Thanks. Another data point to “I believe that GitHub is more contributor-friendly but perhaps not as reviewer-friendly” :)