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-committed repo
- A separate accepter marks those changesets as accepted after a
separate review
- A cron job makes all accepted changesets public.
This allows us to be agile with regards to new changes (i.e. they can be
queued faster), while still being given the option of amending/pruning
changesets that are still not public.
This is not without its issues though. It integrates poorly with
tooling, confuses the contributors (honestly reviewers as well, speaking
for myself) and makes the release process harder. With regards to
tooling, once changesets are on hg-committed they are in a weird phase
of "draft but you can't touch them" where none of the commands will
prevent you from making changes to them (rebase, amend, fold, prune,
etc.) and we still lack some kind of "local prune" in case they get
rejected from hg-committed and need to be rolled back without affecting
the original contributor. Bonus issues: the accept script gets confused
and sometimes publishes changesets anyway in certain conditions, and the
`@` bookmarks gets stuck on an obsolete changeset and needs to be pushed
explicitly. Urgh.
Thinking back over my time contributing to Mercurial, the vast majority
of after-the-fact amends and prunes have been done because of test
failures. This two-phase publication workflow has rarely caught some
*other* cause for removal before it was too late and we needed a
backout/follow-up anyway.
## Proposals for the new process
### Default Heptapod workflow
The most radical of my proposals is that we should adopt the default
Heptapod workflow.
We now have pre-landing CI and a more obvious way of knowing if all
feedback has been taken into account (we can even tell Heptapod to
refuse to "merge" if there are unresolved comments).
Reviewers can still make the decision that they want to wait on the
approval of someone else before merging, and we will still be basically
relying on the good intentions of people with push access to not push
garbage to the repo, just as we are now. Note that this would imply that
contributions coming from the mailing-list need to be sent to Heptapod
by the reviewer (or anybody else, really) in a topic to run the CI first
if we want to be coherent (though we rarely get patches this way nowadays).
### Keeping hg-committed
If the previous proposal to just use the Heptapod default workflow is a
bit too strong and I'm in the minority, we could still have the
two-phase publishing system. It would require some development on
Heptapod's side to allow for that workflow, but Georges assured me it
would be on the easier side.
### A middleground
An in-between solution is to supplement the default Heptapod workflow
with the use of a bot (think Rust's bors). The bot would make sure that
the necessary approval has been given before merging. Such a bot would
need to be one that speaks Mercurial or be simple enough to only need
the GitLab API for rebasing. In any case, a bot solution will need at
least some amount of development as well.
Speaking of development, work in underway to define topic namespaces to
allow for drive-by contributors to more easily get access and to prevent
new users from stepping on each-other's toes when they make mistakes.
# 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.
On 3/10/22 14:28, Raphaël Gomès wrote:
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
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
