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.go...@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@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
--
Georges Racinet
https://octobus.net,https://heptapod.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
