| HN Mirror

Oh hi, and apologies for the slightly late reply.

> would love to see you take a better look at Phabricator as well.

I will. Phabricator was brought into my attention some time ago, not surprisingly around the same time I was looking at the alternatives. I think I should expand on the "does too much" part a bit, because in using that expression I clearly managed to upset you.

Let me state one thing upfront - good engineering workflow is critical. That is also a reason why introducing new tools to existing workflows is so damn hard. And that is precisely why I am looking at tools that integrate into, and enhance the existing setup.

Flag days make everyone unhappy.

From looking at the existing documentation and "pitch pages" for phabricator, I've had the constant feeling of getting overwhelmed. From the list of features you mentioned, I for one don't really see much of a difference between distinct Owners and Herald modules. If code review system has the concept of marking code ownership, then of course automatic notifications for incoming changes in that code should be standard practice.

But the moment CI gets implemented as core module of a code review system, I think it veers off into murky waters. You can't easily smoketest different CI systems. They are tightly coupled with release and deployment tooling, and carry the need for their own notifications. CI is a damn complex beast. I would rather have a very good CI with plugins for the extra functionality than a code repository / review system with a CI slapped on top. If you're going to integrate a CI into code repo (gitlab, I'm looking at you), then you have to aim really high. As in - if you find a regression, and commit a test for it, I would expect the integrated CI to be able to spin off an autonomous bisect run to detect exactly when the regression was introduced.

But let's get back to the subject at hand. The few things I feel are core to a really good code review system:

- Allows to automatically review feature branches, and keeps track of all the changes and comments locally; once the review is completed, the branch can be nuked, but the review remains as a historical item and contains full history

- Default reviewer groups. If a change set touches multiple parts of the code, the relevant people across teams ("owners", in phabricator I think) should all be marked as automatic reviewers.

- Related to the point above, the ability to automatically mark a changeset with "I'm looking at it" if you're doing the review in the web-UI. That would provide visibility for others in the reviewer group.

- Mail in support. Most people get code review comments delivered via email. It should be possible to reply to such a mail, and have the comments from the mail integrate back into the review thread visible in the web UI. If I could use my preferred mail client (mutt, in my case) to respond directly to code review threads, I would be quite a bit happier.

- Some kind of alerting mechanism for "problematic" reviews. If a change set takes ages to review, it usually means that either the change is too complex or too large - or possibly that the reviewer is overwhelmed.

- Again, only slightly related to the previous step: if you are going to integrate CI into a review system, it would be beneficial to see in the under-review section when a change has landed in master that would cause a merge conflict. The probability increases with code age, after all.

And that's just off the top of my head. I mentioned in the sibling comment that I realised RB is built as a product. That comes with its own baggage. In case of Phabricator, I see a an even more complex product. It appears to have so many tentacles that even Lovecraft could have been envious.

There you go.