Moving away from Phabricator

[Raphaël Gomès]

Hi all,

The VM that hosts our Phabricator instance¹ is going out of support in 
June of this year², and this has prompted a discussion in the 
infrastructure mailing-list that has been a long time coming.

Phabricator has been unmaintained for all intents and purposes for a few 
months now, and while its per-commit review tool is actually not too 
bad, it's lacking in basically all other aspects. To say that it would 
be a relief to drop it would be an understatement, sysadmin burden being 
one of the major deal-breakers.

The move to another platform can be thought of as an opportunity to 
think about what's best for the project in terms of health, visibility, 
review and contributions.In the above mentioned discussion, it was 
suggested that the project could switch to Heptapod³.It is no secret 
that I work for Octobus⁴, the company that develops Heptapod, so I am 
obviously biased: I have little to no experience with other Mercurial 
forges and have just been comparing their pros-and-cons on paper, so let 
me make the case for switching to Heptapod as the best choice for the 
Mercurial project as a whole.

Let's get the bad stuff out of the way first: the Web UI performance is 
not great (but not worse than Phabricator's was), the per-commit review 
exists and is fine but not amazing, and finally there is noout-of-band 
contribution.

This last one is arguably a bonus IMO: we are developing a VCS and we 
should be using the VCS to exchange work, dogfooding and improving the 
tool as we go. For those that *really* prefer an out-of-band workflow 
there is still the mailing-list.

We are going to discuss the new contribution process, but I am confident 
that a push/pull-based workflow will be an overall improvement. I cannot 
tell how much time I have lost both as a reviewer and a contributor due 
to the out-of-band workflow and post-landing CI (which can technically 
be two separate issues). Anecdotally, I have heard multiple people 
saying that they would be happy to contribute to Mercurial once in a 
while if the workflow resembled a more modern one, and I can't say I can 
fault them for that. We are not in a position where we are swarmed by 
contributions where filtering the ones that are not quite up-to-par is a 
real issue. (The only other Mercurial forge that I've had some 
experience with is Sourcehut⁵ and while its absolutely stellar 
performance and accessibility are great advantages over Heptapod, the 
email-only contribution system is a definite no-go for me.)

The current default workflow (but not the only supported one) on 
Heptapod is:
- People contribute using topics (from the `topic` extension) which can 
be asked for review through Merge Requests(MR)
- The CI is automatically run on the MR
- MR is approved and/or merged by maintainers
- What happens upon merge depends on the project policy (fast-forward or 
merge changeset), but the result is *currently* always made public.

This workflow has worked quite well for the vast majority of Heptapod 
users (others use named branches), and I've been personally quite 
satisfied with it both as a contribution tool and a review tool in other 
projects.

There are plenty of small adjustments that can be made as to MR policy, 
which brings us to a good point in favor of Heptapod: we have knowledge 
and control within the Mercurial community. If we want to keep the 
`hg-committed` workflow that does not publish automatically for example, 
it's something that can be developed (note that this not my opinion on 
the current `hg-committed` workflow, just being thorough). We are 
currently working on enabling any authenticated user to submit a MR, 
which should help a lot especially with drive-by contributors, who 
currently have to ask for permission on their first submission⁶.

This email started with the mention of our current VM going out of 
support; moving to `foss.heptapod.net` will remove the maintenance 
burden from Mercurial itself with no administrative overhead (and it's 
free!). The current de-facto CI for Mercurial is already hosted on 
`foss.heptapod.net`, so this will only bring more attention to the CI 
and make its use more widespread and simple.

The VCS parts of Heptapod/GitLab represent a pretty small part of the 
entire feature set, basically all other Gitlab Community features will 
be available to us should we use them. One such feature is the issue 
tracker, which is actually quite good. There is a bugzilla integration 
plugin which would allow us to progressively migrate the current 
bugzilla to further reduce sysadmin pressure. Also, like in Phabricator, 
dealing with spam is basically impossible in bugzilla, while it's very 
much possible in Heptapod as we have done in the past on other 
`foss.heptapod.net` projects. This particular issue of migrating 
bugzilla is probably less urgent and can be discussed separately. The 
same goes for further automation of the release process which is 
currently a bit too manual and too bus-factor-y.

>From a sysadmin standpoint, it would be much easier to simply have moved 
to Heptapod before June, removing the need to migrate Phab to another 
VM. From Heptapod's standpoint it's not really advisable to try the 
migration until at least 6.1 is out and used in Heptapod (which should 
be around mid-March) since it fixes a *massive* performance issue with 
exchange. Other roadblocks (like workflow, access rights, etc.) will 
have to be addressed by this point and will determine the course of 
action: they will have to be brought up by people that have been 
contributing and reviewing recently.

Finally, `phab.mercurial-scm.org` will have to become a static archive 
of the relevant parts of Phabricator in its final state so that the 
links to discussion around previous patches still work.

What do you all think?

Raphaël

[1] https://phab.mercurial-scm.org
[2] 
https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/
[3] https://heptapod.net/
[4] https://octobus.net/
[5] https://sourcehut.org
[6] 
https://www.mercurial-scm.org/wiki/TopicPlan#Use_cases_for_topic_namespaces
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20220223/9d07a5ac/attachment.html>