6 ms·

In the past, I've found Gerrit to be reasonably good. Phabricator, on the other hand, not so much. Having worked with MediaWiki in the past on CRs, I think thi

In the past, I've found Gerrit to be reasonably good. Phabricator, on the other hand, not so much. Having worked with MediaWiki in the past on CRs, I think this will be a good move to modernize things for them. When faced with a similar task around the same time at Wikia (now Fandom), we chose GitHub while we were moving off of SVN. I'm glad we did at the time, even without all the additional features GitHub has. I understand why WMF didn't choose GitHub. Compared to their current stack, Gitlab is going to feel like a serious upgrade.

nwah1 6y ago
What features do you think Gitlab lacks compared to GitHub? I haven't used the CI/CD features of either, but PR/MR features seem comparable. Is it the advanced workflow stuff and CI/CD integration where GitHub is better? Bots? I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. But I would be a lot more worried about being locked-in to GitHub than Gitlab.
- rock_hard 6y ago
  Gitlab is worse on almost every angle compared to Github It simply lacks the attention to detail...you can tell that Github walks the extra mile to get the UX right. We used Gitlab for a year and then migrated to Github...it’s a joy!
  - frenchyatwork 6y ago
    Having used both a fair bit, I don't know what you're talking about. If anything my experience has been the opposite. Gitlab had the second mover advantage on a few things, while Github's interface has some weird oddities that seem to stem from the fact that that's how they've always been.
  - cortesoft 6y ago
    Interesting... we used GHE for 7 years and have now switched to gitlab. Gitlab CI, container repos, and Kubernetes integration has been amazing.
- boogies 6y ago
  > I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. It does include git send-mail, and I think Sourcehut’s use of that for issues is nice (and they quote customer claims that “SourceHut mailing lists are the best thing since the invention of reviewing patches.”).
- darkcha0s 6y ago
  Let's not kid ourselves here, it's because GH is owned by MS.
  - bawolff 6y ago
    Its not. This isn't 2000s /. M$ is teh evil!!!11. Its because GH is not available as self-hosted open source. Doesn't matter who owns it. Github was discussed and rejected by wikimedia back in 2012 as well, which was before MS bought them
- brennen 6y ago
  > I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. A few paragraphs I recently wrote elsewhere: The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in design. I rant about this all the time, but there is an entire class of argument about how & whether to use GitHub / GitLab / Gitea / Phabricator / Gerrit / sourcehut / mailing lists / whatever that would mostly vanish if the underlying data model in the de facto standard was rich enough to support the actual work of software development. Because it's not, we find ourselves in a situation where no widely used DVCS is actually distributed in practice, and the tooling around version control is subject to platform monopolization by untrustworthy actors and competitive moats. Code review should itself be distributed/federated, but few of the people involved have incentives to make that happen. It's possible something like https://github.com/forgefed/forgefed https://github.com/forgefed/forgefed will eventually get traction, and Git has been dominant for long enough that I wonder all the time when we might see a viable successor that learns from its fundamental mistake. In the meantime we're forced to choose from a frankly pretty terrible lot of options in the broad structural sense. (For clarity, I'm a WMF employee and am involved in the decision to migrate to GitLab.)
  - judge2020 6y ago
    To me, it sounds like the issue is that you need a central source of truth that everyone can pull from for their purposes, and distributing the code review part doesn't sound like it'll add much. In the current climate, most anyone requesting code review is probably trying to merge into the main central source of truth anyways, so what actual benefit does it bring to either the maintainers or the contributors?
    - brennen 6y ago
      Version control for a genuinely long-lived project is a problem that often outlasts: - Dominant version control and code review system(s) / paradigms. - The current configuration of institutional owners. - Users' trust in an owner / sponsor / maintainer. (Forks happen for reasons.) - The involvement of developers who remember why and how decisions were made. - The trustworthiness of the entities that control services, applications, and network real estate used for development. Some central source of truth is usually necessary, but maintainers and contributors don't benefit when that source of truth is subject to vendor lock-in or can otherwise only migrate at great cost. For all the collaborative benefit that GitHub has undeniably wrought, platform monopolies are eventually a failure mode for end users, at least as for-profit enterprises. With the exception of the dominant silo vendors, nobody in the ecosystem really benefits from being forced to choose a silo that will be hard (and lossy) to escape later. The silos are engineered to limit mobility and channel interoperability to their own ends, for business reasons that run directly contrary to the interests of their users. If the protocol at hand were actually up to the task, we'd spend less effort and anxiety on the problems of all the non-protocol platform tooling that's been built up around it.
Cthulhu_ 6y ago
After reviewing some tools we went with Phabricator ourselves; it's not ideal, but it's open source (read: free, we can't afford a $x / seat license) and self-hosted.
- WrtCdEvrydy 6y ago
  Phabricator is amazing as an all-in-one solution for a small shop.
  - nuritzi 6y ago
    I think Phabricator is a really powerful tool for engineering teams, but when you try to do more cross-functional team collaboration, it's not as user-friendly as GitLab. I used Phabricator at a previous company and miss some functionality, like Phabricator's ability to show issue dependencies in a more intuitive and granular way -- but at that company, we had a lot of trouble getting the Design team to use Phabricator, for example. As OSS communities continue to onboard newcomers, they're faced with a generation that expects modern interfaces that are user-friendly. Having user-friendly tooling also helps promote diversity of OSS communities since it's easier to onboard people with all sorts of backgrounds, since the technical adoption barrier is lowered. I think GitLab is a clear winner here since it's user friendly and designed for cross-functional team collaboration (GitLab dog foods their own product in all departments of the team, so you have HR, Marketing, Finance, etc all using it, in addition to the full product teams). Full disclosure: I work at GitLab as the OSS Program Manager. Part of the reason I joined was because I feel really strongly about GitLab's ability to lower the contribution barrier and get more people involved in OSS.
  - epage 6y ago
    I'm curious about this because I've wanted to get off Phab as soon as I started using it - Whats your thoughts on "arc"? It seems like a whole can of worms of problems you can run into with basic branch flows. I know teams that have complex branch flows and it is a nightmare. Same for Windows users. - What do you use for a CI? How well does the integration work for you? - How is it with tracking conversations on Diffs? - Any particular plugins or bots for it that help make the difference?
20after4 6y ago
What issues did you have with Phabricator? I'm maintaining phabricator for the WMF and I'm interested in anything that could improve the user experience.
- kevincox 6y ago
  I was reviewing code in mercurial's phabrictor and it was awful the most notable was that when a new version was uploaded the comments stayed on the same line number instead of sticking to the same code. There were other annoyances but it would move at least to "ok", maybe even "good" if that was fixed.
  - epriest 6y ago
    This is not (and has never been) the behavior of Phabricator. See <https://secure.phabricator.com/T7447 https://secure.phabricator.com/T7447> for discussion of why this feature can never work the way you think it should work in the general case and why I believe other implementations, particularly GitHub's implementation, make the wrong tradeoffs (GitHub simply discards comments it can't find an exact matching line for). If you believe this feature is possible to implement the way you imagine, I invite you to suggest an implementation. I am confident I can easily provide a counterexample which your implementation gets wrong (by either porting the inline forward to a line a human user would not choose, or by failing to port an inline which is still relevant forward).
    - kevincox 6y ago
      I don't need perfect, I just need good. GitHub and GitLab both have good implementations as well as every other good code review system I have used. GitHub annoying tries its hardest to hide the "outdated" comments but GitLab has the option to keep them open (they are no longer visible in the code, but remain on the discussion tab) So I appreciate your opinion that it is impossible, but as a reviewer I much prefer when the tool tries.
      - epriest 6y ago
abbe98 6y ago
WMF is only replacing Gerrit for now, Phabricator will continue to be the issue tracker.

nwah1 6y ago

What features do you think Gitlab lacks compared to GitHub? I haven't used the CI/CD features of either, but PR/MR features seem comparable. Is it the advanced workflow stuff and CI/CD integration where GitHub is better? Bots? I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. But I would be a lot more worried about being locked-in to GitHub than Gitlab.

rock_hard 6y ago
Gitlab is worse on almost every angle compared to Github It simply lacks the attention to detail...you can tell that Github walks the extra mile to get the UX right. We used Gitlab for a year and then migrated to Github...it’s a joy!
- frenchyatwork 6y ago
  Having used both a fair bit, I don't know what you're talking about. If anything my experience has been the opposite. Gitlab had the second mover advantage on a few things, while Github's interface has some weird oddities that seem to stem from the fact that that's how they've always been.
- cortesoft 6y ago
  Interesting... we used GHE for 7 years and have now switched to gitlab. Gitlab CI, container repos, and Kubernetes integration has been amazing.
boogies 6y ago
> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. It does include git send-mail, and I think Sourcehut’s use of that for issues is nice (and they quote customer claims that “SourceHut mailing lists are the best thing since the invention of reviewing patches.”).
darkcha0s 6y ago
Let's not kid ourselves here, it's because GH is owned by MS.
- bawolff 6y ago
  Its not. This isn't 2000s /. M$ is teh evil!!!11. Its because GH is not available as self-hosted open source. Doesn't matter who owns it. Github was discussed and rejected by wikimedia back in 2012 as well, which was before MS bought them
brennen 6y ago
> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. A few paragraphs I recently wrote elsewhere: The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in design. I rant about this all the time, but there is an entire class of argument about how & whether to use GitHub / GitLab / Gitea / Phabricator / Gerrit / sourcehut / mailing lists / whatever that would mostly vanish if the underlying data model in the de facto standard was rich enough to support the actual work of software development. Because it's not, we find ourselves in a situation where no widely used DVCS is actually distributed in practice, and the tooling around version control is subject to platform monopolization by untrustworthy actors and competitive moats. Code review should itself be distributed/federated, but few of the people involved have incentives to make that happen. It's possible something like https://github.com/forgefed/forgefed https://github.com/forgefed/forgefed will eventually get traction, and Git has been dominant for long enough that I wonder all the time when we might see a viable successor that learns from its fundamental mistake. In the meantime we're forced to choose from a frankly pretty terrible lot of options in the broad structural sense. (For clarity, I'm a WMF employee and am involved in the decision to migrate to GitLab.)
- judge2020 6y ago
  To me, it sounds like the issue is that you need a central source of truth that everyone can pull from for their purposes, and distributing the code review part doesn't sound like it'll add much. In the current climate, most anyone requesting code review is probably trying to merge into the main central source of truth anyways, so what actual benefit does it bring to either the maintainers or the contributors?
  - brennen 6y ago
    Version control for a genuinely long-lived project is a problem that often outlasts: - Dominant version control and code review system(s) / paradigms. - The current configuration of institutional owners. - Users' trust in an owner / sponsor / maintainer. (Forks happen for reasons.) - The involvement of developers who remember why and how decisions were made. - The trustworthiness of the entities that control services, applications, and network real estate used for development. Some central source of truth is usually necessary, but maintainers and contributors don't benefit when that source of truth is subject to vendor lock-in or can otherwise only migrate at great cost. For all the collaborative benefit that GitHub has undeniably wrought, platform monopolies are eventually a failure mode for end users, at least as for-profit enterprises. With the exception of the dominant silo vendors, nobody in the ecosystem really benefits from being forced to choose a silo that will be hard (and lossy) to escape later. The silos are engineered to limit mobility and channel interoperability to their own ends, for business reasons that run directly contrary to the interests of their users. If the protocol at hand were actually up to the task, we'd spend less effort and anxiety on the problems of all the non-protocol platform tooling that's been built up around it.

Cthulhu_ 6y ago

After reviewing some tools we went with Phabricator ourselves; it's not ideal, but it's open source (read: free, we can't afford a $x / seat license) and self-hosted.

WrtCdEvrydy 6y ago
Phabricator is amazing as an all-in-one solution for a small shop.
- nuritzi 6y ago
  I think Phabricator is a really powerful tool for engineering teams, but when you try to do more cross-functional team collaboration, it's not as user-friendly as GitLab. I used Phabricator at a previous company and miss some functionality, like Phabricator's ability to show issue dependencies in a more intuitive and granular way -- but at that company, we had a lot of trouble getting the Design team to use Phabricator, for example. As OSS communities continue to onboard newcomers, they're faced with a generation that expects modern interfaces that are user-friendly. Having user-friendly tooling also helps promote diversity of OSS communities since it's easier to onboard people with all sorts of backgrounds, since the technical adoption barrier is lowered. I think GitLab is a clear winner here since it's user friendly and designed for cross-functional team collaboration (GitLab dog foods their own product in all departments of the team, so you have HR, Marketing, Finance, etc all using it, in addition to the full product teams). Full disclosure: I work at GitLab as the OSS Program Manager. Part of the reason I joined was because I feel really strongly about GitLab's ability to lower the contribution barrier and get more people involved in OSS.
- epage 6y ago
  I'm curious about this because I've wanted to get off Phab as soon as I started using it - Whats your thoughts on "arc"? It seems like a whole can of worms of problems you can run into with basic branch flows. I know teams that have complex branch flows and it is a nightmare. Same for Windows users. - What do you use for a CI? How well does the integration work for you? - How is it with tracking conversations on Diffs? - Any particular plugins or bots for it that help make the difference?

20after4 6y ago

What issues did you have with Phabricator? I'm maintaining phabricator for the WMF and I'm interested in anything that could improve the user experience.

kevincox 6y ago
I was reviewing code in mercurial's phabrictor and it was awful the most notable was that when a new version was uploaded the comments stayed on the same line number instead of sticking to the same code. There were other annoyances but it would move at least to "ok", maybe even "good" if that was fixed.
- epriest 6y ago
  This is not (and has never been) the behavior of Phabricator. See <https://secure.phabricator.com/T7447 https://secure.phabricator.com/T7447> for discussion of why this feature can never work the way you think it should work in the general case and why I believe other implementations, particularly GitHub's implementation, make the wrong tradeoffs (GitHub simply discards comments it can't find an exact matching line for). If you believe this feature is possible to implement the way you imagine, I invite you to suggest an implementation. I am confident I can easily provide a counterexample which your implementation gets wrong (by either porting the inline forward to a line a human user would not choose, or by failing to port an inline which is still relevant forward).
  - kevincox 6y ago
    I don't need perfect, I just need good. GitHub and GitLab both have good implementations as well as every other good code review system I have used. GitHub annoying tries its hardest to hide the "outdated" comments but GitLab has the option to keep them open (they are no longer visible in the code, but remain on the discussion tab) So I appreciate your opinion that it is impossible, but as a reviewer I much prefer when the tool tries.
    - epriest 6y ago

abbe98 6y ago

WMF is only replacing Gerrit for now, Phabricator will continue to be the issue tracker.