Moving away from Phabricator
Georges Racinet
georges.racinet at octobus.net
Tue Mar 1 00:17:25 UTC 2022
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 <http://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 doing on foss.heptapod.net (with help
from our side of course when it comes to expected behavior and
reconfiguration questions). Given the size of the project, I don't think
we can do better on a k8s cluster or a VPS + managed DB. So, my time and
Raphaël's are probably better spent on keeping helping to improve
foss.heptapod.net than on managing a separate installation. For the
record, Octobus also has a small self-hosted Heptapod instance, and
we're thinking of ditching it for the same reasons (basically that
sysadmin requires too much permanent dedication, whatever the
application is).
Also, I understand that the free-of-charge nature of foss.heptapod.net
also would spare us a significant administrative overhead. Getting a SLA
for a free service would probably be asking too much, at least at this
point. I should point out that foss.heptapod.net is managed by the same
people as the commercial service (heptapod.host), and the two instances
are set up in the same way. There is thus a good commonality of interest
between both instances for Clever Cloud and Octobus.
Finally, a Heptapod project can be exported and imported on another
instance. No matter what, we should do regular exports.
>
> 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 hope so, yes.
As mentioned by Raphaël, there is a Bugzilla builtin "integration" in
GitLab. I have not tried it yet, but this could be a nice opportunity to
do so. It could provide an interesting intermediate step, more
streamlined already, if it works with the existing Bugzilla (version
incompatibility is possible, though).
>
> 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?
I like the idea!
There is a compication with the way our "mercurial-devel" Heptapod
project is currently hooked to the official repos at mercurial-scm.org:
we don't accept MRs on mercurial-devel, because the review happens on
Phabricator! Instead, we wait for the automatic pull to mark them as
merged when the changesets get published. People can still click on the
"Approve" button, would that be enough?
I think it's the other way round with evolve, though, but I'm less
familiar with the process there, so I might be wrong about that.
And of course, I'd be happy to provide testing projects for people to
play with.
Best,
>
> 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 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 <http://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
> <http://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
> <http://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 <http://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
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
--
Georges Racinet
https://octobus.net,https://heptapod.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20220301/6afea274/attachment-0002.html>
More information about the Mercurial-devel
mailing list