I see that an advantage is that it doesn't require server-side setup. But wouldn't one require some sort of central repo to coordinate code reviews and CI tests?
This seems to be extremely different to Gerrit. Gerrit requires a centralised server which acts in place of a regular git server. It has its own database, distinct from git, and adds the notion of a "Change ID". Generally you do your review through a web interface. It's all quite clunky, but it does its job very well.
This is distributed but more importantly it looks like it's more entangled/in-tune with git. It says it uses git notes [1], which appeals to me; they're a feature that are basically useless on their own, but seem to be included exactly for the use of something like git-appraise.
Regarding your comment about a central repo, I'd guess the idea is you use git-appraise like you use git today; it's decentralised in the technical layers, but you assign "central" repo in the human workflow layer.
I don't see why. Sure, the CI server would have to be involved in some way to run the tests, but a central server for "coordinating" code review is unnecessary, IMO. Now, as github (and others) have shown, a central place for code review is nice, but as long as the developers had tools that allowed them to work with the code reviews inside their repos, I don't see why a centralized service is necessary.
I asked the Gerrit devs for their opinion: because the git appraise solution doesn't support rebasing it doesn't work well with the idea of being able to fix commits and repush.
Maybe the gerrit developers will be motivated to support this. There has been talk of offline review/moving all metadata to git for some time now.
The point is that you can do reviews locally, push them, and other reviews will fetch. Just as git does not require a central authority, neither does this implementation.
That being said you could still write a web frontend to all of this, ala gerrit.
It does the code reviews in a distributed way. It just needs a central Git repo, but not a central code review server.
CI tests could work in a similar way! Each CI runner is polling for new commits, running tests against them, and pushing the results as git-notes in the Git repo, just like for the reviews.
To me it looks like something that could be used to implement Gerrit, but it doesn't come close to what Gerrit offers, having used it for a few years now. Gerrit is excellent at what it does.
I like Gerrit features, but it always seemed too complicated to integrate into usual coding workflow, especially with people always even complaining about git being "hard to use". This tools seems simpler compared to Gerrit, and more flexible compared to GitHub pull requests.
I would appreciate advices on introducing Gerrit to my team and make it somehow transparent in development workflow.
Once you understand the workflow it's actually easy to adopt. The biggest challenge is getting people to think in terms of push requests instead of pull requests. If you configure the remote as "git config push HEAD:refs/for/master" then it becomes as simple as doing "git push" to upload changes.
This is distributed but more importantly it looks like it's more entangled/in-tune with git. It says it uses git notes [1], which appeals to me; they're a feature that are basically useless on their own, but seem to be included exactly for the use of something like git-appraise.
Regarding your comment about a central repo, I'd guess the idea is you use git-appraise like you use git today; it's decentralised in the technical layers, but you assign "central" repo in the human workflow layer.
[1] http://git-scm.com/docs/git-notes