Moving away from Phabricator

Raphaël Gomès raphael.gomes at octobus.net
Thu Mar 10 13:28:05 UTC 2022 

Hi again,

We will have to start making a decision soon-ish. I'd expect us to start 
figuring out the migration process by early April to have a solid 3 
months before the VM becomes out of support at the end of June (or I get 
tired of responding to low-disk issues on the machine ;) ).

Does anyone have any thoughts or questions on the matter? I know (from 
IRC discussion about Heptapod) that Matt Harbison was planning to at 
least respond to that email but didn't have time to get to it yet, he 
might not be the only one.

To reiterate, we'll need to wait until Heptapod 0.30 (coming to 
foss.heptapod.net at the latest on March 22nd) to try out anything for 
real, but we might as well get ahead of things to plan the work needed.

Raphaël

On 2/23/22 18:25, Raphaël Gomès 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 
> 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
>
> _______________________________________________
> 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://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20220310/af457c55/attachment-0001.html>

More information about the Mercurial-devel mailing list