+1 for switching to git and using gerrit. You appear to be self-hosting plenty as it is, what's one more service? :)
Gerrit is a bit of a bear to host, but it's doable. I think I'd give gerrithub a try first, just because I expect it'd be fine and less costly/time-consuming.
It's also worth noting that nothing prevents us from providing both git and mercurial repositories. Just as I am using hg-git to create a private git repository, so too can it be used to create a mercurial repository from a git repository. Current users can pull from it and continue to use their existing hg-centric workflow.
Just as we could write a script to convert git patch series to mercurial format, the same can be done in reverse. Switching to git will require retooling, so simply consider that as part of the cost. Thus, current mercurial die hards would not be left in the cold; their process should be left virtually unchanged. Mostly. This proposal was all rather off-the-cuff, so there may be use cases that I overlooked.
Indeed, but if we move to gerrit or something like it, there's really no reasonable integration path for mercurial-and-patch-emailers to fit into the new system, unless someone is going to volunteer to proxy for them.
There may be no such holdouts and it won't be a problem, but I think we need to make sure a critical mass is on board before we make such a drastic switch.
I'm willing to re-do the build infrastructure on top of git/gerrit, mostly because it gives me a lot more flexibility to do it right. But, it is a non-trivial amount of work that needs to be done to switch which has to be considered. Especially since people that prefer git can, as you noted, take the work upon themselves if they find it that advantageous :)
--Dan