Re: Moving away from Phabricator

[Raphaël Gomès]

On 4/13/22 22:24, Augie Fackler wrote:



On Apr 13, 2022, at 12:06 PM, Raphaël Gomès 
 wrote:


Hi everyone,

It has now been more than a month and our window to migrate out of 
our VM is closing down.




Thanks for keeping track of this!


Thanks for answering quickly!


I am happy to report that the new versions of Heptapod and the evolve 
extension have brought the expected speedups and the push/pull times 
on Heptapod are now much better. There still remains a lot to be 
desired with regards to exchange, but that is for another discussion.


It's time to make an inventory of the project and make some decisions 
about what stays the same, what changes and what disappears. We also 
need to discuss the contribution and review process.


# Inventory

We still don't have a clear path for VM hosting, but maybe the OSUOSL 
can help us, seeing as a good amount of the foss.heptapod.net 
 CI there. See 
https://osuosl.org/services/hosting/details.


## The mailing lists

They're not going anywhere, of course. Additionally, the ability to 
send patches to the devel mailing list will stay, but will not be the 
preferred way proposed.


They are currently managed by a mailman on the VM, which will need to 
be migrated out. The OSUOSL people have already agreed to manage our 
mailing lists for us. This could be a good solution to further reduce 
sysadmin burden.




If we finish off the lists and phabricator, that reduces our footprint 
a _lot_ FWIW. That removes all (I think?) the reasons we have to send 
mail, so you’re really down to hosting the wiki and the repos.



That would reduce the load significantly, yes. :)



## Phabricator

Phabricator will be turned off and be replaced as a means of 
contribution by Heptapod.


The `phab.mercurial-scm.org ` 
differential URLs will be kept around as a static archive: I have 
already started the relatively painful (basically because of AJAX) 
endeavor of creating the scripts to save the valuable history of our 
review discussions, and hope to have enough free time to have it done 
before the VM dies.


## mercurial-scm.org 

The website will need to be migrated out. I don't expect this to be a 
major hassle.


On a related but technically independent front, I've started some 
very simple patches to improve its contents (like not advertising 
that we use Python 2...).


## Wiki

The wiki needs to be migrated out. I'm not exactly sure what the 
story of MoinMoin is currently, but this should also be a relatively 
simple process.


## Repos

I think the project should still use hgweb to advertise at least its 
main (read-only) repository and any other repo that doesn't have a 
better home. See the part about the contribution process for more 
discussion about the hg-committed repo.




These all sound right.


## Patchwork

What should we do about patchwork? I've only been reminded of its 
existence by looking around the VM. Maybe my `getpatches` alias uses 
it underneath for queuing from the mailing list?




If your getpatches alias is the one I think it is, that probably hits 
https://hgpatches.durin42.com/? Which, as the URL suggests, is 
actually running on a machine I own. It’s been zero-maintenance for 
years, but if y’all care about it long-term we should probably 
transition it eventually. Though it’s not as pressing.


Sure, we'll need to figure out something not too long after. Thanks for 
keeping it running.


## Buildbot

This has been functionally dead for a long while and will not be 
carried over now that we have the Heptapod CI.


## Bugzilla

We will want to - of course - keep our bug tracking. We're using 
Bugzilla with MySQL, but we could use PostgreSQL in the target 
machine if that makes it easier, I don't think this particular aspect 
would be too hard to migrate on its own.


The migration from bugzilla to another tool (like Heptapod/Gitlab 
issues) should probably be another discussion to simplify the transition.




Agreed. Bugzilla has been a pretty minor pain point compared to 
phabricator.


The spam issue has been pretty annoying (same problem as with phab), but 
it's still not as urgent. We only have so many things we can do at once 
single time.


## Other things?

Have I forgotten an important piece of the project?



hgbot runs on mercurial-scm.org . It uses a 
sqlite database and is pretty minimal in terms of overhead, so as long 
as wherever we put the VM can handle the irc connection, seems fine.



Ah, right. This will also probably be fine.



# Review process



I’m inactive enough I’ll defer to the opinions of others here. Others: 
if you have opinions, _please_ speak up! This is your chance to make a 
difference before we EOL phabricator and your choices are (by default) 
heptapod and `hg email`.


[snip review process options]



# Conclusion

The hope of this migration is to remove a lot of the sysadmin burden, 
simpli

Re: Moving away from Phabricator

[Augie Fackler]

> On Apr 13, 2022, at 12:06 PM, Raphaël Gomès  wrote:
> 
> Hi everyone,
> 
> It has now been more than a month and our window to migrate out of our VM is 
> closing down.
> 

Thanks for keeping track of this!

> I am happy to report that the new versions of Heptapod and the evolve 
> extension have brought the expected speedups and the push/pull times on 
> Heptapod are now much better. There still remains a lot to be desired with 
> regards to exchange, but that is for another discussion.
> 
> It's time to make an inventory of the project and make some decisions about 
> what stays the same, what changes and what disappears. We also need to 
> discuss the contribution and review process.
> 
> # Inventory
> 
> We still don't have a clear path for VM hosting, but maybe the OSUOSL can 
> help us, seeing as a good amount of the foss.heptapod.net CI there. 
> Seehttps://osuosl.org/services/hosting/details 
> .
> 
> ## The mailing lists
> 
> They're not going anywhere, of course. Additionally, the ability to send 
> patches to the devel mailing list will stay, but will not be the preferred 
> way proposed.
> 
> They are currently managed by a mailman on the VM, which will need to be 
> migrated out. The OSUOSL people have already agreed to manage our mailing 
> lists for us. This could be a good solution to further reduce sysadmin burden.
> 

If we finish off the lists and phabricator, that reduces our footprint a _lot_ 
FWIW. That removes all (I think?) the reasons we have to send mail, so you’re 
really down to hosting the wiki and the repos.

> 
> ## Phabricator
> 
> Phabricator will be turned off and be replaced as a means of contribution by 
> Heptapod.
> 
> The `phab.mercurial-scm.org` differential URLs will be kept around as a 
> static archive: I have already started the relatively painful (basically 
> because of AJAX) endeavor of creating the scripts to save the valuable 
> history of our review discussions, and hope to have enough free time to have 
> it done before the VM dies.
> 
> ## mercurial-scm.org
> 
> The website will need to be migrated out. I don't expect this to be a major 
> hassle.
> 
> On a related but technically independent front, I've started some very simple 
> patches to improve its contents (like not advertising that we use Python 
> 2...).
> 
> ## Wiki
> 
> The wiki needs to be migrated out. I'm not exactly sure what the story of 
> MoinMoin is currently, but this should also be a relatively simple process.
> 
> ## Repos
> 
> I think the project should still use hgweb to advertise at least its main 
> (read-only) repository and any other repo that doesn't have a better home. 
> See the part about the contribution process for more discussion about the 
> hg-committed repo.
> 

These all sound right.

> ## Patchwork
> 
> What should we do about patchwork? I've only been reminded of its existence 
> by looking around the VM. Maybe my `getpatches` alias uses it underneath for 
> queuing from the mailing list?
> 

If your getpatches alias is the one I think it is, that probably hits 
https://hgpatches.durin42.com/?  Which, as the 
URL suggests, is actually running on a machine I own. It’s been 
zero-maintenance for years, but if y’all care about it long-term we should 
probably transition it eventually. Though it’s not as pressing.

> ## Buildbot
> 
> This has been functionally dead for a long while and will not be carried over 
> now that we have the Heptapod CI.
> 
> ## Bugzilla
> 
> We will want to - of course - keep our bug tracking. We're using Bugzilla 
> with MySQL, but we could use PostgreSQL in the target machine if that makes 
> it easier, I don't think this particular aspect would be too hard to migrate 
> on its own.
> 
> The migration from bugzilla to another tool (like Heptapod/Gitlab issues) 
> should probably be another discussion to simplify the transition.
> 

Agreed. Bugzilla has been a pretty minor pain point compared to phabricator.

> ## Other things?
> 
> Have I forgotten an important piece of the project?
> 

hgbot runs on mercurial-scm.org . It uses a sqlite 
database and is pretty minimal in terms of overhead, so as long as wherever we 
put the VM can handle the irc connection, seems fine.

> 
> # Review process
> 

I’m inactive enough I’ll defer to the opinions of others here. Others: if you 
have opinions, _please_ speak up! This is your chance to make a difference 
before we EOL phabricator and your choices are (by default) heptapod and `hg 
email`.

[snip review process options]
> 
> # Conclusion
> 
> The hope of this migration is to remove a lot of the sysadmin burden, 
> simplify, strengthen and modernize the contribution and review process and 
> leave the project in a healthier, more maintainable state. I hope to see my 
> mental load reduced by a lot after this transition, and I'm pretty sure I'm 
> not the only one.
> 

Thanks a bunch!

___

Re: Moving away from Phabricator

[Raphaël Gomès]

Hi everyone,

It has now been more than a month and our window to migrate out of our 
VM is closing down.


I am happy to report that the new versions of Heptapod and the evolve 
extension have brought the expected speedups and the push/pull times on 
Heptapod are now much better. There still remains a lot to be desired 
with regards to exchange, but that is for another discussion.


It's time to make an inventory of the project and make some decisions 
about what stays the same, what changes and what disappears. We also 
need to discuss the contribution and review process.


# Inventory

We still don't have a clear path for VM hosting, but maybe the OSUOSL 
can help us, seeing as a good amount of the foss.heptapod.net CI there. 
See https://osuosl.org/services/hosting/details.


## The mailing lists

They're not going anywhere, of course. Additionally, the ability to send 
patches to the devel mailing list will stay, but will not be the 
preferred way proposed.


They are currently managed by a mailman on the VM, which will need to be 
migrated out. The OSUOSL people have already agreed to manage our 
mailing lists for us. This could be a good solution to further reduce 
sysadmin burden.


## Phabricator

Phabricator will be turned off and be replaced as a means of 
contribution by Heptapod.


The `phab.mercurial-scm.org` differential URLs will be kept around as a 
static archive: I have already started the relatively painful (basically 
because of AJAX) endeavor of creating the scripts to save the valuable 
history of our review discussions, and hope to have enough free time to 
have it done before the VM dies.


## mercurial-scm.org

The website will need to be migrated out. I don't expect this to be a 
major hassle.


On a related but technically independent front, I've started some very 
simple patches to improve its contents (like not advertising that we use 
Python 2...).


## Wiki

The wiki needs to be migrated out. I'm not exactly sure what the story 
of MoinMoin is currently, but this should also be a relatively simple 
process.


## Repos

I think the project should still use hgweb to advertise at least its 
main (read-only) repository and any other repo that doesn't have a 
better home. See the part about the contribution process for more 
discussion about the hg-committed repo.


## Patchwork

What should we do about patchwork? I've only been reminded of its 
existence by looking around the VM. Maybe my `getpatches` alias uses it 
underneath for queuing from the mailing list?


## Buildbot

This has been functionally dead for a long while and will not be carried 
over now that we have the Heptapod CI.


## Bugzilla

We will want to - of course - keep our bug tracking. We're using 
Bugzilla with MySQL, but we could use PostgreSQL in the target machine 
if that makes it easier, I don't think this particular aspect would be 
too hard to migrate on its own.


The migration from bugzilla to another tool (like Heptapod/Gitlab 
issues) should probably be another discussion to simplify the transition.


## Other things?

Have I forgotten an important piece of the project?

# Review process

Moving to Heptapod will imply a change in review process.

## Default Heptapod workflow

Here's what the expected workflow would look like (this is *not* an 
exhaustive list of all possible workflows):

    - Contributor creates their changesets locally and affects them a topic
    - Contributor pushes their changesets to the repository to test 
them against the CI, which launches automatically on the tip of their 
topic (the push is refused if not in a topic, or if it's a public 
changeset for non-maintainers, of course)
    - Contributor decides that their changes are good enough to review, 
they create a merge request (MR) associated with their topic (either 
from the web UI or through push options). Note that that's what happens 
today, but at some point we may want to reduce the duplicate pipelines, 
e.g., limiting pipelines to MRs could become necessary.

    - Reviewer reviews the MR:
    - Both make comments back-and-forth either on the general diff, 
or on the individual changesets
    - The changesets get updated on each push with context as to 
what changed since the comments were made
    - MRs that need adjusting  are put in the Draft state and 
assigned to the original author
    - Reviewer "merges" the MR. This does not imply a merge and can be 
forced to always rebase (and wait for a green CI). Doing so manually, 
mainly for taking a series partially, is entirely possible with a normal 
`push --publish` (though this would not run the CI before publishing, 
which we will need to think about). In any case, removing the topic from 
a draft also **makes the changeset public** upon push.


That last point is important and we need to evaluate how we want to go 
forward.


## Current process

The current review process goes as follows:
    - One committer pushes the draft changesets to the hg-

Re: Moving away from Phabricator

[Raphaël Gomès]

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.

Re: Moving away from Phabricator

[Georges Racinet]

Hi Greg,

On 2/27/22 20:45, Gregory Szorc wrote:
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?


Yes, there's been improvement on that front in GitLab. I'm not sure when 
your last experience was, so let me summarize the features as of today:


- from a Merge Request (MR), one can go to the "Commits" tab to review 
them individually. On a given commit, there are Prev/Next buttons when 
appropriate.


- Comments left on individual commits are displayed on the MR overview, 
like any comment, and have to be resolved. There are niceties like "Jump 
to next unresolved thread" and the like.


- Comments can be posted immediately or "added to the review" (kept as 
drafts) and sent together once the review is done (quite similar to 
Phabricator I believe)


- If a new version of the MR is pushed, thus making a commit obsolete, 
its comments are still visible, with an indication that it was made on a 
previous version. There isn't yet a tracking of the successor (I bet it 
would be problematic with Git).


- In the "Changes" tab, you can review the whole diff (as you say), and 
also compare subsequent versions of the MR. This is in my opinion 
something that is lacking in Phabricator. I like for instance to review 
patches individually, and do a last sweep of the whole diff after 
corrections have been made, right before I hit the merge button.


As far as I remember, Heptapod has no specific code about the review 
process. There is a significant chunk of specific code related to Merge 
Requests, but that is for merge detection: properly ending the MR as 
"merged" if a push did merge or publish the changes.


There is still room for improvement :

- comments on commits are tied to lines of code, so one has to comment 
the first line or the last one for stuff relevant to a whole commit 
(including the message). This is annoying, but not a blocker in my book. 
It's probable that an improvement on this will be merged upstream sooner 
or later (there is IIRC at least one attempt). Perhaps we'll end up 
helping with that.


- as mentioned above, tracking of successor to show a comment in the 
context of the successor in case that's useful, or simply to show the 
diff between obsolete changeset and successor is not implemented (we 
could have something specific to Mercurial, here)


There are some after-the-fact examples of the process in existing 
projects, such as https://foss.heptapod.net/heptapod/hgitaly or 
https://foss.heptapod.net/mercurial/hg-git. I would have to check to 
give you precise examples.




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.


On the general principle, this makes sense. In practice, we (Octobus) 
are in permanent contact with our partner hosting company (Clever Cloud) 
and we do fix things together pretty quickly. The latest example was the 
hotfix that came with GitLab 14.6.5 a few days ago.


If I'm not mistaken, a major cloud provider would provide us with 
working systems or containers, and managed DB servers, but we'd still 
have to care about the application itself. That means proper monitoring, 
backups, applying upgrades in a timely manner, and people on alert. This 
is the work that Clever Cloud is do

Re: Moving away from Phabricator

[Gregory Szorc]

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 
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 s

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 an