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@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
