Moving away from Phabricator

Sun Feb 27 19:45:57 UTC 2022

I agree we should move off Phabricator since it is unsupported. This is
painful for me to say, as the stack-based reviews that this project
practiced on Phabricator is the best code review workflow I've practiced
and seen in my career.

As for what's next, I'd say Gerrit probably has the next best review tool
for commit stacks. Review Board gained better support for commit-by-commit
reviews in the last year or two (but I have yet to use it). Gerrit,
unfortunately, is heavily wedded to Git. I'm not sure if we could shoehorn
Mercurial to work [well] with Gerrit even if we tried. So that may rule it
out.

I do like the idea of having a more streamlined experience for things like
running CI along with your review submission. I also like not having to
think about maintaining this infrastructure or consolidating so there are
N-1 services to manage. So Heptapod/GitLab on paper is probably the best
solution here.

What I don't think I like about Heptapod/GitLab is that the stacked review
experience wasn't that great the last time I looked. Mercurial has
(correctly IMO) established a strong opinion around the use of microcommits
and actively encourages review units to be as small as possible to help
drive down the defect rate. And last time I looked, GitLab really
emphasized the merge diff and makes it a lot harder to review individual
commits. Is this something that has improved with GitLab recently or has
been improved with Heptapod? Can you show an example of a stack-based
review on Heptapod?

There is another concern around how much the Mercurial Project should rely
on 3rd party infrastructure not hosted by major cloud providers. You
definitely have peace of mind when there is a formal contract or SLA in
place. I'm not saying we couldn't get that from foss.heptapod.net - just
that it is a discussion that needs to take place.

I also like the allure of ditching Bugzilla for something more integrated.
That's not a slight against Bugzilla as much as it is an opinion that
having greater cohesion between issue tracking, version control, and code
review will likely yield a better overall experience.

I think a concrete next step here is trialing code review on Heptapod.
Maybe start sending some reviews to the patches mailing list so people can
get a feel for what the experience is like?

On Wed, Feb 23, 2022 at 10:45 AM Raphaël Gomès <raphael.gomes at octobus.net>
wrote:

> 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 no out-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
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20220227/0cd69333/attachment-0002.html>