I joined Eventbrite shortly after they moved from Review Board to Phabricator for code review about 4 years ago. It took me a little while to adjust, but once I did I found it to be superior to what Github provided. The CLI provides a nice way to standardize on a workflow company-wide. The UI for composing a review has a few quirks but a lot of functionality, and the patch-based aspect makes it easy to track the evolution of a diff. Herald is very powerful for making sure the right people review a diff. Conduit provided what we need to integrate with Jenkins for CI.
Github has gotten better since then, but I'd still lean toward Phabricator as the better tool for code review, especially for larger projects.
I eventually partially inherited running Phabricator at Eventbrite, and found it overall to be straightforward to configure and troubleshoot. We were only running a single node and using git for repositories, though. Now I'm at Mozilla, and we recently switched from Review Board to Phabricator for Firefox code review. Some of my teammates run the service, and I know that running a multinode setup with mercurial as the repo format has proven challenging.
I didn't use it long enough to really figure out if this is a purely aesthetic concern and I'm just being stubborn about the way I'm used to or if it leads to real problems in practice. I'm curious what people who really like Phabricator think about this.
I can't truly speak for them, but I suspect these are both (reworking the history of code while its in review, and multiple people working on a branch) things that the Phabricator authors would say are bad practices that your tools should discourage. The arguments that come to my mind are
1) Reworking history during review makes it near for your reviewers to understand what is changing. That should be reserved until its time to merge your code, at which point all the revisions along the way should be squashed.
2) Shared development on a branch means the scope of the change is large, and the branch is probably long-lived too. Both of these are arguably bad; I don't have time to argue why, but chapter 13 of Continuous Delivery lays it out well.
Really, it's a lot like the mailing list model: you may develop incrementally in whatever way you want, probably between multiple people, but at the final stage you're going to need a clean set of delineated patches to submit for review and someone takes ownership of that part (90% of the time that's you, maybe not you if you're on a multi-person feature). These are more or less two different steps in the development cycle.
This basically happens anyway in my experience at a certain point, even if using GitHub, depending on how your team develops... For example, we recently had a long-lived (~2 month) branch open that accumulated about 300 commits and diverged from our upstream master at $WORK. It implemented a large feature, between many components, and during that time had to be revised in a few ways, due to unforeseen (but minor) things. We didn't just do a direct merge; we assigned individual people subsets of the work, and they were responsible for bringing in the changes in a reliable way. This turned 300 commits into something like 30 or 40. This part of the development is basically the last step, and it took time for us to bite-size the pieces. But then the actual review step -- and submitting the patches -- is a very small part at the end.
A lot of projects like LLVM follow basically the same model (they use Phabricator too but that's more a coincidence, nothing to do with the general flow): the final patch stage is a very separate part from the development stage, all things considered, and posted patches for big features rarely reflect actual development. So, I think putting yourself in this mindset helps. GitHub completely ties the notion of a branch to be both "A thing you use for development" and "The thing that the reviewer finally sees" by way of PR, but clearly this is more a design choice on their part -- rather than a fundamental property of git.
Regarding abstraction, there is a thing about this, which is that you mostly interact through Arcanist to submit patches. This admittedly adds complexity and can confuse people if they think `arc` is just identical to `git`. We had to teach a lot of people to use Arcanist for Haskell.org. This can absolutely be considered a real downside. Admittedly though, Arcanist is an abstraction, and it also works for SVN and Mercurial, so if you have multiple types of repos -- that's arguably very useful! For homogeneous VCS setups, though, I can see how it only seems to add complexity. Realistically, the review stage where you interact with Arcanist is pretty small in the overall development cycle with most changes, but people are still sensitive to it.
Honestly I don't think it's a big deal at all, and in fact I find Phabricator's model quite a bit nicer than GitHub's in some incidental ways too, because of it. One nice thing is that you don't have a trillion dead forks of popular repos, search across all patches is unified, stuff like that...
Personally, I really liked it, except for the fact that the interface feels clunky and outdated. When I was leaving, the company was moving to GitLab mainly to use the "pull request" flow, which is not available in Phabricator.
- One of the main repo is a monorepo in Git with over 40~ services
- We have a lot of smaller repos that are outdated or depreciated.
- We have an extensive pipeline that builds Docker images using Google Cloud Container Builder
Here's the pros:
- Speed. Gitlab is so slow; it's actually one of the main reasons why we moved out of it.
- Phabricator's Maniphest > Gitlab Issues by a long shot
- We prefer patch-based workflow. It makes Git history pretty.
- Code review is so much better in Phabricator, again, by a long shot. It's faster and the experience is a lot better.
- Herald (if-this-then-that for source code) is the bomb. We have a big list of rules, example: detecting `dangerouslySetInnerHTML` in our frontend service and adding blocking reviewers.
- Git management is pretty dope, setting it up so that it mirrors somewhere else is pretty easy. In our case, we just made it so that it mirrors to Google Cloud Repository (for GCCB to work)
- Cluster mode is included, which is useful because we're setting up a mirror Phab Repo in Russia for our team there
- Meme editor makes things more fun (but its kinda shitty that it doesn't accept GIF =\)
- The dashboard editor is very powerful and useful.
- We had teams using SVN and teams using HG. Phab supports them all. That's pretty cool.
Here's the cons:
- Harbormaster, the CI, is the worst. It's seriously super complicated and not powerful at all.
- To replace Gitlab CI, we moved to Buildkite since there's an integration with Phab. Buildkite is a lot more powerful than Gitlab CI, and the syntax is similar.
- The concept of "staging" repo is super confusing.
- Setting up "merge" from the UI is very complicated and buggy
Pros of buildkite:
- Very powerful. Plugin system is amazing and easy to extend. We wrote our own buildkite-docker executor, and I merged a lot of parts from it to the docker plugin upstream
- UI is a lot prettier and responsive than Gitlab's
- Dynamic pipelines !
- Hooks are extensive and powerful. Precheckout, Checkout, PostCheckout, precommand, command, postcommand. You got it all.
- The GraphQL API is amazing, and probably one of the best API I've used in my life.
- Pipelines are composable. You can make a yaml include another yaml. This was our biggest gripe with Gitlab since we use a monorepo and it got pretty big
- I know for a lot of people it doesn't mean a lot, but I like emojis in the output
- Agents are not stored like Gitlab. In Gitlab, once an agent connects, it gets stored in the database and never disappear until you delete it. It's problematic for our use case, because we use pre-emptibles node to save cost. It's 30% of the real price, and it dies every 24 hours. after 3 months, our Gitlab got super slow because it retained all the infos on all runners that existed. I had to make a script that deleted it from the database.
- Job retries!
- Docs are pretty dope
- Annotate is very cool (https://buildkite.com/docs/agent/v3/cli-annotate)
- Block step. Useful for confirming before deploy or something.
- Pretty cheap (unlimited builds, you pay per user). Honestly, I would love to pay them more.
Cons of buildkite:
- It's not free, so Gitlab is hard to beat on that.
- Gitlab works fine for 99% of the use case.
Take a look at their changelog, a bunch of screenshots and you'll see their development pace =)
Their front-end is open source: https://github.com/buildkite/frontend
However, if you add your own CI runners, you'd have to clean them up periodically. This was the biggest issue for us, because even after cleaning them up from all docker images once a week, builds would get stuck.
Gitea is written in Go. I used it for a small self hosted instance; it's fast for me, but I wonder if it scales well.
Is Gitea any better?
I hear that's exactly the reason why Gitea forked from Gogs.
In the past month, Gitea merged ~110 pull requests and got 70 new issues, and Gogs 7 and 18. Gitea also has 1500 (30%) more commits. All of this indicates to me that Gitea is further along than Gogs. Mainly based on that I went for Gitea and I like it so far, but I didn't install Gogs so I can't compare directly.
Still, that doesn’t help much. Gitea just does a lot less than Gitlab behind the scenes.
See https://gitlab.com/gitlab-org/gitlab-ce/graphs/master/charts for the core server.
Since then php got faster, laravel copied many Rails concepts and improved in many areas. PHP is getting more popular while Ruby/rails is losing marketshare.
Those who still compare are living in the past.
We prefer patch-based workflow.
It makes Git history pretty.
With Github, you'll end up with a history like:
Implement feature A
Merge #1 Implement feature A
Implement feature B
Merge #2 Implement feature B
A big commit is harder to revert (without encountering conflicts).
Implement feature A
Implement feature B
"Merge branch 'dev-hello' into 'master'"
Phabricator makes it so that the squashed commit summary is the summary of the diff (merge request)
But like the parent said, it's not nearly as fancy.
Depending on who you are ask, Gitlab today is usable or Ok. I don't think anyone would call it fast. I wish they could write up where those bottlenecks are.
You need to throw quite a lot of hardware at it for acceptable performance.
That said, I always found Phabricator's issue tracker (Maniphest) to be superior to GitHub Issues, with ability to create task dependencies (parent/child) and ability to limit tasks permissions only to few selected groups (with spaces). It's possible to setup Phabricator to mirror other repositories if you want to use only its issue tracker.
Gerrit works similarly, but Phabricator's UI is much more friendly.
For small projects or teams, the overhead of introducing a new tool may not be worth it, for for large projects with many contributors, the workflow is - in my opinion - strongly superior.
If you set Github to "squash and rebase" and enforce a "one PR per idea" rule, you will get a pretty similar workflow. The tooling isn't quite as polished, but it's sufficient for many projects.
> As far as code reviews go, this is pretty spot on. I was part of a a startup that was using GitHub pull requests for code reviews. As the team grew, it became more and more intractable, although not simply because of notifications. Side-by-side diffs and checkpointed diffs (so that you can see what changed since the last round of review and whether/how your comments were addressed) are handled very poorly by GitHub. We ultimately switched to Phabricator, and while there was a little friction as folks got acquainted with the new tool, it made code reviews a much more pleasant process. Recently, I had to go through a full code review back on GH pull requests, and it felt like pulling teeth in comparison. They're fine for interacting with contributors to an open source project, but compared to working with a tool like Phabricator that's built for a code reviewer's workflow (and for teams of engineers working together on a project), they just don't hold a candle, in my opinion.
(from a previous discussion: https://news.ycombinator.com/item?id=7697132)
I've heard that complaint a lot. How are these things handled poorly by GitHub? It's an honest question; I've only used GH and a bad, ad-hoc, poorly-thought-through Perforce workflow, so I may not know what I'm missing, but it has always seemed quite simple for me to scroll through a pull request and see feedback (either tagged to lines of diff or general), and commits that address pieces of feedback. Then you can click on each commit to view it, or open the full hairball diff to see how those changes end up in the final result. What's missing there?
It sucks when someone puts a bunch of unrelated changes in one commit, or when their commit message is bad ("code review"), but those seem like they'd be problems regardless of GitHub.
I've looked at patch-submit-discuss/mailing-list-style workflows, and they seem fine. The discussion is definitely more front and center. However, when people submit updated patches it seems like I'd want to be able to easily tell what changed between their first iteration and second iteration of the patch--i.e. did they actually address the feedback they got? This can be hard to see, especially if a patch is substantial or to confusing/repetitive code. I can download all the submissions and run diff on each pair in sequence, but that seems like needless hassle when, unless the feedback was "throw it all out and do it a totally different way" (which, in a branching workflow, is often a good reason to start on a fresh branch), subsequent iterations could be submitted as a "patch to a patch", with an easy way to view the cumulative diff. At this point, it would basically be a branch workflow. Are there solutions for this in the patch-submit-discuss model?
Basically, when changes are requested, the patch based work flow is to submit a revised set of commits up for review. In Github, one can do that by either force-pushing to the branch that's currently attached to a pull request, or one can push up a new branch and open up a new pull request associated with that branch.
But there isn't a way to view the "interdiff" between the version of the branch before review and the version of the branch after review. Review tools like Phabricator, Gerrit, and email lists allow one do view that diff.
Yes there is. You even get a link to view that exact diff whenever someone updates a PR. It shows changes since you last viewed the PR, up to its current state.
Why would you do that, in general? That seems needlessly hostile to reviewers, since then they have to go through your diff and make sure you caught every place their comment applied (e.g. "did they actually handle the else-case everywhere they're testing on $var?").
Is this common practice in situations* where it harms diff readability? If so, why?
* There are totally cases where that's necessary, but they don't seem like more than a small minority of comment/feedback/amendment cases. These are times like "you put all of this code in the totally wrong place" or "this is missing a fundamental assumption that would require you to totally rearchitect every change you wrote". In those cases, a rebase (plus clearly calling out "everything was rebased starting here please start reading from here on!") or a brand new branch is in order.
The main purpose is to maintain a clean set of commits. So rather than having a history like:
Add method and unit tests
Update version to 1.2.3
Fixed issue in method
Fixed syntax error
Addressing review comments
> That seems needlessly hostile to reviewers
Why would doing something like this be considered hostile? The problem here is the tool used for reviewing code, not the submitter or reviewers. Other review tools have had the feature of viewing the diff of the branch across rebases for quite some time now.
The only other alternative is to rely on the submitter to make sure they squash the amendments they make into the correct commit. That in itself is more difficult after making multiple commits of that nature. What usually happens in that case is that those commits end up as part of the master branch. This makes it more difficult to revert certain changes because they're split across multiple commits and it also makes it more difficult to track down the source of a bug. It also makes it more difficult to see which commit was responsible for a given change when using git blame.
a) Given an arbitrary case, is there a chance that modifying commits is considered a poor practise in that case?
b) Is the belief that modifying commits is poor practise held by the population at large?
The answer to a) is yes, the answer to b) is no.
Some people prefer a clean history, where you have to explicitly request the steps to get to it if you want them. Others want the messy steps to be part of the history you show up-front.
Ideally, a commit should be self contained and change only one thing. This means that a feature would consist of multiple commits.
Since later commits may depend one or more earlier commits (some of which may be in the same feature branch), how do tools that work on a commit based workflow handle those dependencies?
You usually try to avoid dependencies. If you can't avoid them, have a series of patches depend on each other.
Phabricator supports stacking patches. Here's a random patchset:
Scroll down to "Stack" - it will display the list of patches depending on each other:
I don't think that is accurate. Or there kernel its very common to submit whole patch series (branches), and to rebase them on the latest kernel. Phabricator makes multi commit reviews possible but a total pain.
We had a big Wiki page for newcomers on how to setup arcanist, and it was not that funny.
My impression, coming from tools like gerrit, bitbucket/stash, fisheye/crucible and google3 is that phab is a review tool that kind of wants to be a source control tool, but it fails at both. I actually dread putting up reviews when I upstream stuff to FreeBSD because I hate phab. I've found that it is just easier for me to use the "upload patch" feature than it is to use their arcanist tools on top of git or svn. I really wish the project would move away from this tool.
Since switching to Fisheye/Crucible, code reviews have become so easy we do them all the time as part of the normal workflow. I really can't imagine switching back nowadays.
Phabricator is primarily aimed at teams with multiple approximately-full-time engineers working on projects together, and focuses more on scaling up to thousands of engineers than scaling down to personal projects. It may be a poor fit for your needs if you're looking to move very small projects away from GitHub following the acquisition by Microsoft.
Can you guys advertise more? I hear about Atlassian on NPR and my IT team has guys fully sold on their stuff but my team has been operating very cleanly off a Phabricator VM for years now. However IT keeps pushing me to go all Atlassian so they can "support it". I'm like, yo, git pull every few months to upgrade and keep the VM patched. They're like but Atlassian has conferences.
What should I do?
For us, Crucible was a significant improvement over Phabricator in terms of daily use. My team had been trialing it for several months, and upon demoing it to other teams and our managers, convinced them it was worth switching.
Supporting self hosted gets even more murky, documentation tends to be stale, updates tend to be in place and high availability is hit or miss.
I hope they will add a "git push"-based workflow to accommodate this use case.
Wrapping git is essentially a flawed idea; there are just too many corner cases (rebasing, resetting etc) for a wrapper to handle them all.
I also remember having some issues with Arcanist on Windows.
For example, if you merge a reviewed commit into two different branches and then god forbid you try to merge those two branches, Arcanist will fail with a cryptic message - and you'll only realize that this is arbitrarily/buggy-ly forbidden only when you try this workflow several times...
Vanilla-git or even a Bitbucket/GitHub/GitLab style pull-request style workflow gives you so much flexibility that Arcanist just takes away from you, and the only way to learn these quirks is the hard way....
Whereas gitlab/github etc are much more flexible, but also slower to use and more demanding that your individual developers adhere to your standards.
I think Phab is best for projects of 3-5 to 50 (basically until your project is dealing with multiple commits per hour and no single repo is going to be painless), especially when you have new team members and you'd rather let the the tools enforce the workflow as opposed to policing them yourselves. However, if you don't like that workflow, you're never going to be happy with Phab.
Finally, Phab has some really nice features that I haven't seen elsewhere, like posting lint errors inline in the merge request.
Arcanist is not a Git wrapper - you can (and should) use Git normally. All Arcanist does is automate the process of creating and uploading patches, and applying remote patches.
It's completely fine and quite useful for someone to say that their experience was bad with a tool in general on an internet thread about the tool in general.
The `arc` command did rewrite my branches, ruin my revisions or otherwise do something buggy a handful of times, particularly with `arc update`.
We do use Maniphest, the issue tracker component, heavily. And it's pretty great, honestly. I find it to be a useful blend of exposed functionality and ease of use.
That said, we don't use Differential, the code review component for most (any?) teams. Instead we're pretty entrenched on gerrit still, and I haven't seen any signs of that changing over the last few years.
But also a bit scary:
> Review others' code with Differential, because they can't be trusted.
Don't take it too seriously.
> Phabricator has more than 300,000 lines of PHP, so there are probably at least sixty or seventy million security vulnerabilities in the project. Virtually limitless wealth!
The software itself is similarly whimsical
They are just embracing the steriotype sarcastically.
"Phabricator uses a lighthearted tone in documentation and some interfaces, and includes some features which primarily exist to add flavor or make things sillier.
We use this tone because we like building software like this, and the feedback we receive about it from users is overwhelmingly (and often effusively) positive."
1. The title's seeming attribution to Wikimedia as opposed to Facebook (or even Phacility) is like, whatever the opposite of dog whistling is
2. If you want to host your own things, great; do that. Phab is great, gitlab is also pretty neat. If you want someone to manage this stuff for you, Phacility is out there grindin' but they also have like O(10) employees, so don't expect miracles
3. The point of GitHub was always about "social coding"; the concerns about overcentralization aren't unfounded but it's also not like that wasn't straight up the value proposition in th the first place!
If everyone moves off to their own walled gardens, something of value will be lost. So like, again: love phab (it/arc's my favorite code review workflow, I think the conventions it adds on commit messages are really valuable (and btw trace right back to Facebook eng culture), the pretty tight integration of tools is nice, I enjoy its sense of humor), but I think calling it meaningfully a true GitHub alternative, with any consideration of FOSS, is inaccurate
Disclosure: I left a startup using phab (at my urging) and GitHub at the end of March and now work at Microsoft (where my team has some code on VSTS and some on GitHub). I first encountered Phab as an intern at FB in 2011, when epreistly had just left
I’ve also tried to volunteer add to a project on github but whenever a pull request depends on another, it gets messy. Rewriting history all the time to make commits easier to review has been a pain.
The Sourcegraph extension for Phabricator is open source at https://github.com/sourcegraph/phabricator-extension.
If you are considering switching from GitHub to Phabricator, definitely give this integration a try. Would love to hear feedback! Will post a demo video soon.
It's very well-designed and has support for enterprise features like ldap, clustered servers, CI, etc. and there's no distinction between community/enterprise versions -- it's all open source. Other great features are task management, wiki, blogs, question/answer (a la StackOverflow), and of course memes/macros which add some lighthearted fun to code review. The engineering behind the product is top-notch which is evident from reviewing the tasks/discussions behind features , or even reviewing the source code. One killer feature for my company was Spaces, which allows setting up "walled gardens" -- we use it to allow external collaborators to create tasks, etc. without being able to see anything outside their own space.
Managing and maintaining Phabricator is pretty straightforward. It's a standard LAMP type of product (Linux, Apache, MySQL, PHP) which is easy for myself or IT to jump on and diagnose issues. It's the only tool I've seen which will also alert administrators to identified issues with configuration (when logged into web page). Additionally administrators of the tool do not have blatant all-access to projects, though that might be niche.
I'm glad it's getting more notice now, even if it's largely due to Microsoft acquiring GitHub. I don't know if Facebook uses Phabricator still but WikiMedia does and I belive the Mercurial development team is considering it . Phabricator is a great product and worth trying out. Their community is located at  - they used to allow open access to their self-hosted Phabricator instance but it became too noisy as the user base grew so they've moved to discourse forums.
Last time I heard, multiple teams at Facebook are using it.
Say I have a local repo, but don't host my own domain. Suppose I could run something which connects to the peer-to-peer rendezvous server, which provides a web presence for my repo.
Then suppose that the clone URL served by this repo would just put the user in contact with my IP address to do the git clone from me directly.
The public server facilitates the contact and provides a presence.
Patching this into git would help. Suppose git supported some htt2p://foo.bar/baz URL which connects to foo.bar, and retrieves a special dynamic resource baz which redirects it to the current location of baz; e.g. git://x.y.z.w/whatever/baz
People that want to host code on the internet just need to pay the fee to put it on the internet. Once its there, anyone can download it.
Hopefully the fee is trivial, I'm guessing this wouldnt be a problem since it would be less popular than Bitcoin.
original article: https://blog.printf.net/articles/2015/05/29/announcing-gitto...
Took me a while to get to grips with the 'fun' spelling all over the place though. I know there is a 'serious' mode, but that it way too serious! :)
Agreed that serious business mode is slightly too serious. I miss the acsii dragon when pushes were denied by heralds.
Unfortunately I never got around installing and using it, as it heavily relies on PHP installed as command line tool (for preparing a change for pre-submit code review).
One particular manifestation of the prior point is that, for me, it worked best with a one-commit-per-unit-of-work workflow, where stacks can be merged on a commit-by-commit basis and code review issues are addressed by editing the changes into the relevant commits. In Git, making this work is a painful amount of history rewriting that lands you in a world of rebase pain. In Mercurial, you just fix things at the top of the stack and `hg absorb` the changes into their relevant commits. `hg absorb` is, in fact, the one Mercurial command I really wish I had in Git.
Disclaimer: This is my app and btw I'm running a WWDC promotion and you can download it for free till Friday: https://itunes.apple.com/us/app/easygit/id1228242832?mt=12
The idea of tying a repository to a specific project was great. As was being able to in-line issues directly in a pull request.
However when I went to spin up a new project, and stack for myself, earlier this year. I went through the major options and settled on GitLab. I'm doing this on the public site, with public repositories. So can't speak to the pains of self-hosting.
But phabricator I think is still a great alternative if you want to use it on site. Another benefit is being able to mix and match source control systems
The value added by github is primarily that you can get drive-by patches submitted because it's become the tool that so many developers both already know how to use and already have an accountse. Phabricator is much more focused on providing value to set teams working on a project, and it does that really, really well.
I would point out the very wide feature set for a development team, beyond code hosting and review. A couple of times I was thinking " we should set up a web app with this", only to find it with a few clicks that Phabricator already had it. A few gems:
- pastebin-like app
- Instant chat
- task manager with planning
None of them are top-of-the class, but it's helpful to have them all in the same setup.
The amount of control is actually rather nice.
It is less invasive, doesn't include issue tracking.
I wish gitea could be used as a file manager(file explorer), i.e. with folders on the side and I can navigator files and review them easily, sort of like the linux 'ranger' command inside browser, I know this is asking too much.
It's only really for code review though. No nice web UI for browsing repositories, no issue tracking, etc. This was a plus for us (very unix-y and easy to integrate with existing systems), but could be seen as a negative.
* The UI is getting better, and you can tweak the CSS, it's pretty simple.
I looked at GitLab, Bitbucket, and Phabricator. I selected Phabricator because it provides more control for moderation and managing workflows and it's 100% open source . Some examples of ways Phabricator can be customized:
- Create a custom "New Bug Report" form with fields for reproduction steps, expected results, actual results, software version, operating system, etc. Customized forms are more than just a Markdown template. (This is the first bullet point from Dear GitHub.)
- Provide instructions on how to fill out each custom form. You can customize the blurb at the top of each form using Remarkup (similar to Markdown). (This is the third bullet point from Dear GitHub.)
- Keep security issues restricted to a private group until they've been resolved.
- Default user-reported issues to private until they've been triaged. (This could help alleviate the expectation to publicly reply to all spam.)
- Require users to acknowledge the contributing guidelines before submitting a feature request.
- Access to forms can be customized with ACL groups, which can be used to moderate spam by granting or revoking access to features based on users' behavior.
- Require signing a CLA or DCO before submitting a patch. This has first-class support since Phacility requires a CLA for contributions to Phabricator.
- Tasks can have subtypes, such as "feature" and "bug." (You can also do this with "project" tags, but I think Phacility's plan is to use subtypes to extend the custom fields functionality.)
Phabricator also has some nice extras that weren't part of my decision criteria:
- It has a built-in blogging application (Phame), which could be used to publish release notes or important changes (e.g., "Upcoming Breaking Changes in v2.0"). A feed of these news items can be added to a custom dashboard along with commit and task activity to help users keep up to date.
- A built-in polling application (Slowvote) can be used to solicit feedback.
- A Q&A app (Ponder) could be used to help answer users' questions without cluttering the issue tracker. Unfortunately, this app currently lacks some customization and moderation capabilities.
- Paste is for sharing snippets (similar to Gist).
- Flags can be used to bookmark anything you want to remember to come back to with an attached note.
- Pholio is a review tool for mockups. I probably won't need this for my peronsal projects, but I thought it was a cool idea.
Phabricator comes with some trade-offs. The downsides that I've noticed:
- There isn't a good hosted option for open source projects. Phacility provides hosting at $20/user/month, but if you have to pay $20/month for every user that signs up to file an issue, that's financially unviable for an open source project. Personally, I prefer self-hosting, so this isn't an issue for me. I'm mentioning it because I know others will prefer a hosted solution.
- Navigating the UI isn't as smooth out of the box. Some common tasks require an extra click or two compared to GitHub or GitLab. Some of it can be alleviated by customizing the places where you want a direct link. For example, you can add a link to a repository in a project's sidebar. (Projects are independent of repositories, so they're not automatically linked.)
- It's meant to be customized, so it's not as simple as just install it and start using it right away. It takes some time to setup and migrate projects.
- Many of the tools that aren't core functionality (repos, tasks, code review) are MVP quality. This includes the CI tool (Harbormaster) , the Q&A app (Ponder), and the human intelligence queue (Nuance)  among others.
- Phacility's focus is on enterprise customers, so it's not clear how issues that are unique to open source projects will be prioritized. I haven't seen this be a problem and it's used by some prominent open source projects (FreeBSD, GnuPG, Wikimedia), but it's worth mentioning as a possibility.
I've been playing around with Phabricator on a FreeBSD instance on DigitalOcean. For anyone else considering Phabricator, note that the page response time is greatly affected by the instance type that you choose. A standard droplet on DigitalOcean or any of the VC2 instances on Vultr provided about a 1 second response time (measured by Nginx's $request_time in the logs). A CPU optimized droplet on DigitalOcean provides about a 100 millisecond response time and results in a noticably more responsive UI. I can't speak to the response time on EC2 instances, because I've only tried hosting providers with first-class FreeBSD support.
 "No special editions. Everything included, open and free" (https://phacility.com/phabricator/).
 The documentation for Harbormaster says that all it's really good for is to notify an external CI system (Jenkins, Buildbot, etc) to trigger a build and then to receive build results. It doesn't have any built-in capability of running builds.
 Nuance seems like it has potential as a triage queue for user-reported feature requests and bug reports, but it currently lacks the necessary customization.
(Edited for formatting.)
Glasgow Haskell Compiler
I can't remember in what context that was, but ever since I heard that, I have been wanting to try Phabricator out. I guess this is as good an opportunity as any!
Clone via https://secure.phabricator.com/source/phabricator.git
It's managed at https://secure.phabricator.com/