1. 59

Phabricator is the bug tracker and/or code review platform for KDE, LLVM, GnuPG, Wikimedia and more.

  1. 31

    Phabricator was the one remaining project manager I actually liked, after FogBugz and Kiln imploded. I’ve used it at half the companies I’ve worked at, including my current one. It’s not perfect, but it had a really solid take on code reviews (including support for pre- and post-commit flows), had universal ticket numbers for all projects, supported Mercurial, had decent email support,…just lots of great stuff. There’s nothing comparable left in the space, IMVHO

    Separately, this announcement is odd to me. No project handoff. Just days of warning before our support contract is useless, if I read this correctly, and only two months guaranteed to migrate off. It seems to be instantly mothballing something people use in such a way it won’t survive because…reasons? I don’t know that I’ve seen an open source project shut down this way before.

    1. 10

      Word is Evan Priestley was the solo maintainer.

      1. 12

        Yeah; that’s been true for awhile. I’m 100% sure this was burnout. When Fog Creek spun off Kiln, the management floated the idea of me buying it. Ignoring cost considerations, the revenue was such that it’d have either just been me, or maybe me plus one dev. That’s just not enough to maintain something complicated like that, that needs to have bare-minimum four nines uptime, and not run out of momentum at some point—and Phabricator simply does way more than Kiln did, since it’s also a wiki, bug tracker, chat system, blog platform, and so on.

        I don’t blame him for burning out. I just wish he’d done more of a hand-off, but that is ultimately up to him.

      2. 2

        By my reading, you get until the end of August to migrate off, so that’s an extra month. And it does say that your instance will stay up past that time; perhaps data export is part of the “very limited support” you still get after that period?

        I do agree it seems funky though. I’d expect more like a year to migrate off for paying customers, which I’m assuming from context users of the hosted instance are.

        Though I guess now there isn’t a company left that will suffer because people didn’t like that it didn’t give enough migration time?

        1. 5

          By my reading, you get until the end of August to migrate off, so that’s an extra month. And it does say that your instance will stay up past that time; perhaps data export is part of the “very limited support” you still get after that period?

          There’s definitely a couple ways you could read this, but my read is that he’ll make a sincere effort to keep things running, and definitely not intentionally take things down until after August 31, but that traditional uptime guarantees, support windows, and feature work are not things anymore as of tomorrow. [Edit: I do appreciate that he’s saying people “should expect very limited support after August 31, 2021”, which is obviously not June 1, but I’m also laser-focused on the fact that support pacts are not renewable/we aren’t going to be billed anymore as of tomorrow, which sure implies to me they’re no longer active.] In that case, while “indefinite” could mean years, and most likely means months, I can’t really bet my company on that; we’ll need to move to something else before 8/31 to be safe.

        2. 1

          after FogBugz and Kiln imploded

          What happened with FogBugz? Last I checked it’s still up and running.

          1. 3

            Fog Creek sold it to fund Glitch. I hate the new owners, but that’s kind of moot, because they quit developing it, as far as I can tell. I moved all my stuff off years ago.

        3. 16

          I’m on the Wikimedia Foundation team responsible for our Phabricator instance. We’re in the thick of implementing a migration from Gerrit to GitLab for code review, so the timing of this is not my favorite thing.

          Anyway, Phabricator is easily the best system for managing tasks/bugs in a large group that I’ve used or administered (my points of comparison are many and varied), and I don’t have any desire to stop using it. This is genuinely good software that deserves a healthy community fork.

          1. 5

            We are using Phabricator for VyOS and we cannot migrate to GitHub’s issue tracker simply because that thing can’t track issues across multiple projects—even if we wanted to lock ourselves into GitHub, it simply doesn’t meet our requirements.

            I believe Phabricator deserves a fork. Should we all start a Phabricator user group to discuss what to do and how?

            1. 3

              Does there happen to be a writeup for Wikimedia’s reasons to switch from Gerrit to Gitlab?

              1. 7

                Yeah. We ran an extensive community consultation on whether to do so. Let me dig up relevant links:

            2. 5

              I’m sad to see this. In my previous job at CodeYellow, we used Phabricator’s ticket tracker extensively. The other features we didn’t use so much, but just the ticket tracking and especially the Kanban-like project boards were extremely useful in giving insight in a project. In my new job at bevuta IT we’re using Redmine and I absolutely hate it. It’s like a worse, more enterprisey version of Trac; I can never find anything in it.

              For CHICKEN, we’re still using Trac, and for all its limitations it’s acceptable, at least for smaller projects it is. I certainly don’t hate it, but I don’t love it either. Is there any decent ticket tracker out there? The GitLab and GitHub trackers are okay for bug tracking in tiny projects, but they’re not that great for feature planning and development. And for larger projects they’re effectively useless.

              1. 2

                I have yet to see a ticket tracker that serves all uses well. We’re tracking a very large project in Jira and it’s working well, though that’s partly because of the API and some custom stuff we’ve built on top. Oh and “working well” also includes “annoying slow at times” and “fairly expensive”. Jira can be made to do almost anything.

              2. 4

                At the job I just left we used Phab and I liked it a lot. It was good at enforcing standards. Sad to see that there is no business in that. Github is eating everything, it seems.

                1. 4

                  LLVM is gradually in the process of moving to GitHub code review. Phabricator has a few nice features (in particular, the idea of dependent revisions, so you can have one PR on top of another and have it automatically rebased on head when the first is merged) but the UI is awful. It’s marginally better if you use arc on the command line, but then you need a load of PHP goo installed on your dev machine to do things that GitHub does just with git commits (Phabricator supports multiple revision control systems, but these days it’s mostly used with git). It’s currently a big barrier to new contributors because figuring out how to use Phabricator is a painful learning experience.

                  1. 4

                    Github PR review UI is far behind Phabricator usability.

                    1. 3

                      That’s subjective. In my view, GitHub’s PR interface does about 70% of what I want and it’s sometimes annoying when I find myself in that 30%, but it works very well for the 70% that it does. I hope that over time it will evolve to fill in the rest. In contrast, Phabricator does 400% of what I want and it does most of it badly. There’s always a way of doing what I want with Phabricator, but it invariably involves spending ten minutes reading docs. I’ve never read documentation on GitHub’s PR interface.

                      To give an example, here is one of the most common things I do in a PR that I have no idea how to do in GitHub that I have no idea how to do in Phabricator: suggest a small change. With GitHub, I select the range of lines I want to modify and add a comment with a ```suggestion block in it. This can then be merged into the PR branch directly from the web UI. I presume something similar is possible in Phabricator (at least allowing the person to pull the change back with arc) but I’ve never done it.

                      I’ve occasionally written a review with GitHub and forgotten to submit it, but it’s quite rare because the comment UI differentiates between leaving a single comment and starting a review. After I’ve started a review, I know that I need to do something explicit to finish the review. Phabricator is always in ‘start a review’ mode and so I think around 60% of my Phabricator reviews have ended up sitting there until I go back the next time someone comments and discover my draft is still there.

                      1. 3

                        We’ve found GitHub’s UI to have improved a fair bit in recent years, getting closer to parity with Phabricator. One thing in GitHub’s favor is its API: we’ve got a team using GitHub and they really like some of the Slack integration they’ve set up more than the Phabricator dashboard, for example.

                        We’ve also found that it’s more effort to get engineers up to speed with Phabricator than with GitHub for PRs.

                        1. 3

                          I agree that engineers are already familiar with Github. I don’t use Phabricator anymore, but I recall that the “context” around a diff was much better than Github. This is especially relevant when reviewing C/C++ where the surrounding context is of utmost importance in order to track objects’ lifetime (yes even if you use RAII).

                          1. 1

                            Yes, context around a diff was definitely much better in Phabricator than GitHub. This has gotten better on GitHub in recent times, though I haven’t done a detailed look at the two to see if Phab is still better.

                      2. 2

                        FWIW, you can replicate dependent revisions on GitHub with what GitHub users call “stacked PRs”.

                        Given branches main, feature/A and feature/B such that feature/A is a dependency of feature/B, creating a PR from A to main and B to A will automatically update the base of the latter to main when the former is merged.

                        I’ve personally found the experience to be quite clunky whenever I’ve had to do it, but the option exists. There’s definitely space here for some CLI automation.

                        1. 4

                          I’ve seen this, but it has the annoying property that you have to merge the PRs into each other and so things don’t end up in trunk until you’ve merged the last one. The Phabricator model lets you merge each feature and rebase, which avoids big divergence.

                      3. 1

                        I wonder if this will push users looking for an all-in-one solution into the arms of Jetbrains space. Nervertheless, this leaves a hole in the OSS space, unless some fork with traction emerges.