In late September, I participated on behalf of Logilab to the Mercurial 4.4
sprint that held at Facebook Dublin. It was the opportunity to meet
developers of the project, follow active topics and forthcoming plans for
Mercurial. Here, I'm essentially summarizing the main points that
held my attention.

Amongst three days of sprint, the first two mostly dedicated to
discussions and the last one to writing code. Overall, the organization was
pretty smooth thanks to Facebook guys doing a fair amount of preparation.
Amongst an attendance of 25 community members, some companies had a
significant presence: noticeably Facebook had 10 employees and Google 5, the
rest consisting of either unaffiliated people and single-person representing
their affiliation. No woman, unfortunately, and a vast majority of people with
English as a native or dominant usage language.

The sprint started by with short talks presenting the state of the Mercurial
project. Noticeably, in the state of the community talk, it was recalled
that the project governance now holds on the steering committee while
some things are still not completely formalized (in particular, the project
does not have a code of conduct yet). Quite surprisingly, the
committee made no explicit mention of the recurring tensions in the project
which recently lead to a banishment of a major contributor.

Facebook, Google, Mozilla and Unity then presented by turns the state of Mercurial
usages in their organization. Both Facebook and Google have a significant set
of tools around hg, most of them either aiming at making the user experience
more smooth with respect to performance problems coming from their monorepos
or towards GUI tools. Other than that, it's interesting to note most of these
corporate users have now integrated evolve on the user side, either as is
or with a convenience wrapper layer.

After that, followed several "vision statements" presentations combined with
breakout sessions. (Just presenting a partial selection.)

The first statement was about streamlining the style of the code base: that
one was fairly consensual as most people agreed upon the fact that something
has to be done in this respect; it was finally decided (on the second day) to
adopt a PEP-like process. Let's see how things evolve!

Second, Boris Feld and I talked about the development of the evolve extension
and the ongoing task about moving it into Mercurial core (slides). We talked
about new usages and workflows around the changeset evolution concept and the
topics concept. Despite the recent tensions on this technical topic in the
community, we tried to feel positive and reaffirmed that the whole community
has interests in moving evolve into core. On the same track, in another vision
statement, Facebook presented their restack workflow (sort of evolve for
"simple" cases) and suggested to push this into core: this is encouraging as it
means that evolve-like workflows tend to get mainstream.

Another interesting vision statement was about using Rust in Mercurial. Most
people agreed that Mercurial would benefit from porting its native C code in
Rust, essentially for security reasons and hopefully to gain a bit of
performance and maintainability. More radical ideas were also proposed such as
making the hg executable a Rust program (thus embedding a Python
interpreter along with its standard library) or reimplementing commands in
Rust (which would pose problems with respect to the Python extension system).
Later on, Facebook presented mononoke, a promising Mercurial server
implemented in Rust that is expected to scale better with respect to high
committing rates.

Back to a community subject, we discussed about code review and related
tooling. It was first recalled that the project would benefit from more
reviewers, including people without a committer status. Then the discussion
essentially focused on the Phabricator experiment that started in July.
Introduction of a web-based review tool in Mercurial was arguably a surprise
for the community at large since many reviewers and long-time contributors
have always expressed a clear preference over email-based review. This
experiment is apparently meant to lower the contribution barrier so it's nice
to see the project moving forward on this topic and attempt to favor diversity
by contribution. On the other hand, the choice of Phabricator was quite
controversial. From the beginning (see replies to the announcement email
linked above), several people expressed concerns (about notifications notably)
and some reviewers also complained about the increase of review load and
loss of efficiency induced by the new system.
A survey recently addressed to the whole community apparently (no official
report yet at the time of this writing) confirms that most employees from
Facebook or Google seem pretty happy with the experiment while other community
members generally dislike it. Despite that, it was decided to keep the
"experiment" going while trying to improve the notification system (better
threading support, more diff context, subscription-based notification,
etc.). That may work, but there's a risk of community split as non-corporate
members might feel left aside. Overall, adopting a consensus-based decision
model on such important aspects would be beneficial.

Yet another interesting discussion took place around branching models.
Noticeably, Facebook and Google people presented their recommended
(internal) workflow respectively based on remotenames and local bookmarks
while Pulkit Goyal presented the current state to the topics extension and
associated workflows. Bridging the gap between all these approaches would be
nice and it seems that a first step would be to agree upon the definition of a
stack of changesets to define a current line of work. In particular, both
the topics extension and the show command have their own definition, which
should be aligned.