Phabricator: An open source, software engineering platform(github.com)
github.com
Phabricator: An open source, software engineering platform
https://github.com/facebook/phabricator
18 comments
My favourite:
* Written in PHP so literally anyone can contribute, even if they have no idea how to program.
* Written in PHP so literally anyone can contribute, even if they have no idea how to program.
When I read the page I couldn't tell if it was serious or some sort of April Fool's joke that someone forgot to take down and almost immediately dismissed it as something that people would actually use.
Personally I interpret language like that as "built by developers, for developers", as opposed to the "built by a committee of graphic artists and lawyers, to appeal to the CEO who imposes random decisions upon developers" feel that I get from most enterprise software...
Doesn't that worry you?
It would worry me if I were Phabricator, or if I were trying to get others to buy into using it in a professional environment.
Anecdotally, we get much more positive feedback about the tone and copy than negative feedback. It's certainly possible we're just not hearing the negative feedback, but we get plenty of other negative feedback about other things, so this would be an unusual blind spot.
The tone of the project itself is similar to the tone of the site, so if you find it off-putting or believe your co-workers would find it unprofessional, the product may not be a great fit for your environment anyway.
We also haven't heard feedback about anyone having difficulty convincing others to try Phabricator because of the project's tone. Again, it's possible we're just not aware of it, but we have heard feedback about other issues in this vein (for example, the LAMP stack being a hard sell).
The tone of the project itself is similar to the tone of the site, so if you find it off-putting or believe your co-workers would find it unprofessional, the product may not be a great fit for your environment anyway.
We also haven't heard feedback about anyone having difficulty convincing others to try Phabricator because of the project's tone. Again, it's possible we're just not aware of it, but we have heard feedback about other issues in this vein (for example, the LAMP stack being a hard sell).
Evan, thanks for all the hard work on this project.
We use it every day at work. At first we were like, what is this 'Clowncopterize' button? But then we enabled the serious business flag and we were off and running.
We use it every day at work. At first we were like, what is this 'Clowncopterize' button? But then we enabled the serious business flag and we were off and running.
Thanks!
We also just got rid of "Clowncopterize":
https://secure.phabricator.com/D8812
We also just got rid of "Clowncopterize":
https://secure.phabricator.com/D8812
Ahh... please leave this in as an option. The funny terminology is one of the best parts of Phabricator! I think removing this is sad...
I meant to imply that if a little dry humour scares you away from an open source project, then maybe that says a little about you, too.
My favourites are the menu items at the bottom.
We use Phabricator at Bloomberg and I'll take the opportunity to shamelessly plug the add-on tools we've open-sourced to make working with it even easier:
https://github.com/bloomberg/phabricator-tools
https://github.com/bloomberg/phabricator-tools
We use phabricator. It has some really nice features.
* Easily automatic updating.
* Really nice code reviews.
* Many features built in.
It also has some very terrible downsides:
* It expects you to use its work flow (though you can work around it) for merging code back into master.
* It requires manual config per git repository.
* arcanist is a pain to install (and php)
* Its expectations don't seem to quite match up with gits. It seems to often have trouble figuring out what I'm trying to send for code review. I've given up on it being smart and now just always run: `arc diff master` or `arc diff master --update D<ID>`.
* Easily automatic updating.
* Really nice code reviews.
* Many features built in.
It also has some very terrible downsides:
* It expects you to use its work flow (though you can work around it) for merging code back into master.
* It requires manual config per git repository.
* arcanist is a pain to install (and php)
* Its expectations don't seem to quite match up with gits. It seems to often have trouble figuring out what I'm trying to send for code review. I've given up on it being smart and now just always run: `arc diff master` or `arc diff master --update D<ID>`.
If you're having issues, let us know. Offhand:
1. `arc land` is optional, and always has been. If you don't want to use it, you can just use normal `git` commands. All `arc land` gives you is a few checks against human error.
2. `.arcconfig` is no longer required, although if you want to use integrations like lint, you'll still need to configure them.
3. Anything we can improve on?
4. You should be able to use `arc which` to understand what `arc diff` will do. You can change what `arc diff` will do by specifying a different set of "base" rules, according to this document:
https://secure.phabricator.com/book/phabricator/article/arca...
1. `arc land` is optional, and always has been. If you don't want to use it, you can just use normal `git` commands. All `arc land` gives you is a few checks against human error.
2. `.arcconfig` is no longer required, although if you want to use integrations like lint, you'll still need to configure them.
3. Anything we can improve on?
4. You should be able to use `arc which` to understand what `arc diff` will do. You can change what `arc diff` will do by specifying a different set of "base" rules, according to this document:
https://secure.phabricator.com/book/phabricator/article/arca...
We use Phabricator at my company. It's a fantastic issue and task tracking tool kit. The addition of Arcanist and it's integration with git is awesome. Highly recommend trying it. I've used a lot of similar systems of the years (bugzilla, Jira, and others). Phabricator blows them away.
First used phabricator as an intern, and later brought the toolset for class projects (Compilers and now thesis-work). It's been massively helpful, and like others have commented, their IRC is active and helpful.
FWIW, a friend who'd never used the tool got up and running (after a kind of messy install) in less than 2 hrs. For any other undergrads out there doing any serious project work with people, this is worth your time. I mostly use it as a personal task-manager (asana would do the job), but I like how good its command line tools are, and how I can do just about anything from terminal.
FWIW, a friend who'd never used the tool got up and running (after a kind of messy install) in less than 2 hrs. For any other undergrads out there doing any serious project work with people, this is worth your time. I mostly use it as a personal task-manager (asana would do the job), but I like how good its command line tools are, and how I can do just about anything from terminal.
This has long since spun off of Facebook into a company working on phabricator full time:
http://phabricator.org
http://phabricator.org
Well that would explain the high churn that I've been noticing with my tool. I've always been curious about why they were iterating at the pace that they are.
Here's Phabriactor's weekly code churn
http://screenshots.gitsense.com/phabricator-churn/
And its weekly lines of code change
http://screenshots.gitsense.com/phabricator-churn/loc.html
Here's Phabriactor's weekly code churn
http://screenshots.gitsense.com/phabricator-churn/
And its weekly lines of code change
http://screenshots.gitsense.com/phabricator-churn/loc.html
LLVM is using Phabricator for code reviews, seemingly very effectively: http://reviews.llvm.org/differential/
I know for instance that the Rust project has had some frustrations with Github when it comes to code reviews, possibly for issue tracking too. Does anyone have any experience with phabricator as a bug tracker?
I know for instance that the Rust project has had some frustrations with Github when it comes to code reviews, possibly for issue tracking too. Does anyone have any experience with phabricator as a bug tracker?
Phabricator was one of the first tools I brought to my latest company. We primarily use it for Differential because the arcanist command line tool is so easy to use. Even those that are somewhat git challenged benefit as it handles merging commands for you when you land a review.
The IRC channel is a great place for Q&A and epriestley et. al. are always there to offer help.
Before you bash it for being written in PHP, take a look at the source; it is unlike any other PHP code I have ever seen.
The IRC channel is a great place for Q&A and epriestley et. al. are always there to offer help.
Before you bash it for being written in PHP, take a look at the source; it is unlike any other PHP code I have ever seen.
Don't take this the wrong way but this is still PHP and I say this as someone that's been writing in PHP since 2001, although I've largely shifted away. It didn't take me long to find some really crazy stuff like these nested try-catch blocks in:
https://github.com/facebook/phabricator/blob/master/webroot/...
Also this comment is pretty telling:
https://github.com/facebook/phabricator/blob/master/webroot/...
Also this comment is pretty telling:
// If execution throws an exception and then trying to render that exception
// throws another exception, we want to show the original exception, as it is
// likely the root cause of the rendering exception.
I wrote this code, but I'm not sure what's wrong with it. Can you explain what's bad about it and how you'd improve it?
---
To provide some context, this is the top-level entry point for all requests. It routes requests to code which does application-level things, like showing a code review or updating a task or whatever.
When the application-level things go wrong, we try to display a pretty, human-readable exception page with a nicely formatted stack trace (if you're in developer mode), etc. This page relies on some infrastructure subsystems (like configuration, to check for developer mode, and static resources, to include JS and CSS, and rendering, to actually produce the HTML) working correctly.
Normally, the exception is in application code and everything works fine. We produce a pretty page and send it back to the user.
However, sometimes there's an error in one of these subsystems. If we start rendering the page and encounter a second exception during rendering, we fall back to a less-pretty page which has bare text and no dependencies on subsystems. Normally, this happens during development when you've made a mistake in changing one of the subsystems, and all JS inclusion or all configuration checks are failing.
On this bare page, we want to retain the original exception (as well as show the followup exception) because it may be helpful in identifying and resolving the issue.
With the obvious caveat that I wrote the code, this architecture seems sensible and appropriate to me, and appears to function correctly in practice.
---
To provide some context, this is the top-level entry point for all requests. It routes requests to code which does application-level things, like showing a code review or updating a task or whatever.
When the application-level things go wrong, we try to display a pretty, human-readable exception page with a nicely formatted stack trace (if you're in developer mode), etc. This page relies on some infrastructure subsystems (like configuration, to check for developer mode, and static resources, to include JS and CSS, and rendering, to actually produce the HTML) working correctly.
Normally, the exception is in application code and everything works fine. We produce a pretty page and send it back to the user.
However, sometimes there's an error in one of these subsystems. If we start rendering the page and encounter a second exception during rendering, we fall back to a less-pretty page which has bare text and no dependencies on subsystems. Normally, this happens during development when you've made a mistake in changing one of the subsystems, and all JS inclusion or all configuration checks are failing.
On this bare page, we want to retain the original exception (as well as show the followup exception) because it may be helpful in identifying and resolving the issue.
With the obvious caveat that I wrote the code, this architecture seems sensible and appropriate to me, and appears to function correctly in practice.
I apologize for the late response I was looking at more of the code trying to get a better feel for what it is actually doing.
To answer your question, I'd start with why you are worried about exceptions in rendering your exceptions? Whatever you are using to render your exception should be so simple and stable that you shouldn't need to worry about it.
Also another question, from a fairly quick glance and I admit I didn't read through every last line of code, it appears as if all application execution is wrapped in a try/catch block, instead of exceptions being caught and handled closer to the potential points of failure is there a reason for this?
And one nitpick, because it was kind of a pain to follow some of the code but nested if/else statements five/six layers deep are generally kind of discouraged.
Thanks for taking time out of your weekend to respond and good luck to your team!
To answer your question, I'd start with why you are worried about exceptions in rendering your exceptions? Whatever you are using to render your exception should be so simple and stable that you shouldn't need to worry about it.
Also another question, from a fairly quick glance and I admit I didn't read through every last line of code, it appears as if all application execution is wrapped in a try/catch block, instead of exceptions being caught and handled closer to the potential points of failure is there a reason for this?
And one nitpick, because it was kind of a pain to follow some of the code but nested if/else statements five/six layers deep are generally kind of discouraged.
Thanks for taking time out of your weekend to respond and good luck to your team!
You have to rethrow exceptions in other languages too. What's wrong with this?
Phabricator is definitely interesting. In my limited time with it I really took a liking to it.
Unfortunately, to me, the Atlassian toolchain still wins out over it, provided it's within the budget. I vastly prefer Jira's Agile boards to anything else I've ever used, and it's integration with Stash and Bamboo just make things absolutely lovely.
But I mean, as long as it's not Mantis.
Unfortunately, to me, the Atlassian toolchain still wins out over it, provided it's within the budget. I vastly prefer Jira's Agile boards to anything else I've ever used, and it's integration with Stash and Bamboo just make things absolutely lovely.
But I mean, as long as it's not Mantis.
Phabricator looks so useful, however the one time I tried setting up it up I found it to be an absolutely horrific experience. The documentation was so so and I could never figure out some weird issues with permissions that prevented me from ever getting it to work properly. I really wanted to like it, but I got the impression that so many comprises have been made to it to accommodate the needs of every single development team out there and their esoteric set ups. It would have been much better served saying no to features and promoting a plugin-based approach where you get a dead simple set up out of the box and then extend it as necessary. The fact that there are several dozen configuration guides doesn't help much:
https://secure.phabricator.com/book/phabricator/
I'd love it if someone started a project like phabricator but in community with a decent package manager and robust module ecosystem like node.js, python, go or ruby, with go or node.js being my first choices. Large monolithic projects with half-baked plugin management and profiteering seems to be a recurring theme in the PHP ecosystem (joomla, drupal, magento, wordpress). I feel that a project like this birthed in one of those other communities would promote a much simpler core product the can grow with your needs.
I'm really not trying to hate but just vent some frustration.
On the other hand, looking at the site today, it looks like it might have changed a lot since when I first tried it like 2 years ago. Might have to give it another go.
I'd love it if someone started a project like phabricator but in community with a decent package manager and robust module ecosystem like node.js, python, go or ruby, with go or node.js being my first choices. Large monolithic projects with half-baked plugin management and profiteering seems to be a recurring theme in the PHP ecosystem (joomla, drupal, magento, wordpress). I feel that a project like this birthed in one of those other communities would promote a much simpler core product the can grow with your needs.
I'm really not trying to hate but just vent some frustration.
On the other hand, looking at the site today, it looks like it might have changed a lot since when I first tried it like 2 years ago. Might have to give it another go.
I still use the redmine which supports git well for me, for all my software stuff plus acting as a nice project management tool. I wish it's not developed in Ruby, so I could have one less language(and its dependencies) to maintain on the server side.
how does this compare to redmine, or gitlab?
Interesting read on Phabricator vs. Asana: http://www.quora.com/What-does-Asana-give-you-that-Phabricat...
Wikimedia is seriously looking into replacing Bugzilla and Gerrit with this. http://www.mediawiki.org/wiki/Phabricator
Here is a running phabricator:
https://secure.phabricator.com/
https://secure.phabricator.com/
If anyone is interested in trying phabricator on demand (SaaS) - check out phabricator.io
Unfortunately, this requires MySQL. I guess it would be okay if you're already running that but I'd rather not introduce a third database daemon (after Postgres and Redis) to my servers.
I like the implication that MySQL is the unfortunate technology choice here, rather than PHP. :)
I can follow instructions, but only one of these actually compiles.
EDIT: managed to compile it, it's just the RPM that wouldn't build :P (still wouldn't dare run this on the servers though)
EDIT: managed to compile it, it's just the RPM that wouldn't build :P (still wouldn't dare run this on the servers though)
What's so baffling is a behemoth that attracts some of the top engineers would settle for 2 vastly inferior technologies. To be fair, it is a glorified todo / commenting system.
MySQL works pretty well when you treat it as an unreliable network-accessible key/value store; and PHP works pretty well if you treat it as a pure templating language, and also write your own implementation, and also rewrite the language itself to be a different, better language :P
Well, you could look at Gerrit Code Review. It can use its built-in database (H2), MySQL, or Postgres.
its amazing, how good and easy it is to setup the phabricator.. looks like a well trained system
Another garbage heap of php technology from everyones least favorite personal data peddlers.
Who cares.
Who cares.
I must say, there is one concern that keeps me away from using otherwise great Facebook technologies like Phabricator and React is that I don't believe Facebook will be here in 5 or 10 years.
What will happen to these projects if that is the case?
What will happen to these projects if that is the case?
Phabricator has been independently developed for about three years now. Check the main project page for details:
http://phabricator.org
The GitHub URL will probably change if Facebook vanishes, but the project would otherwise be unaffected.
http://phabricator.org
The GitHub URL will probably change if Facebook vanishes, but the project would otherwise be unaffected.
> I'm mad because I can't rationalize how a company I dislike can make something of value so I'm going to make butthurt posts on HN about it.
Keep it up buddy.
Keep it up buddy.
http://phabricator.org:
http://phacility.com/: