Encouraging best practices through server communication

[Angel Ezquerra]

On Tue, Dec 10, 2013 at 11:41 AM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> From my experience observing dozens of developers work on a large Mercurial
> project (Firefox), it's increasingly apparent to me that a large chunk of
> Mercurial users are failing to harness some of the basic features of
> Mercurial, much less adopt some of the "advanced" practices we prescribe for
> Firefox development (including a slew of custom extensions).
>
> While I think the out-of-the-box Mercurial experience could be more
> proactive about certain features (e.g. more UX only extensions like color
> and pager enabled by default, "advertisements" about related commands and
> functionality, etc), there are scenarios where vanilla Mercurial alone
> doesn't know about best practices. For example, let's say you have written a
> custom Mercurial extension to make interacting with your repo better. It
> provides custom hooks to ensure linting before push, etc. You /really/ want
> people to install it because it's so awesome and makes your code better.
> Unfortunately, getting the message out through traditional channels is hard
> (say it's a large, distributed, open source project). What other methods are
> available to us?
>
> I put together a "best practices" Mercurial extension [1] to try to solve
> this problem. Essentially, the server detects when clients don't have this
> extension installed and alerts them to install it. When a client has the
> extension installed, it asks the server to describe its recommended best
> practices. The server sends down some metadata (minimum client version, what
> extensions to have installed, etc) and the client self-checks its
> conformance and notifies/prompts about "violations." The client can even
> auto-install extensions from the repo URLs specified by the server!
> Effectively, the server prescribes a set of best practices for interacting
> with it and the client helps the user achieve that state.
>
> While the extension isn't finished and has yet to be deployed outside of
> testing, I thought I'd share it with this list for a few reasons. First, I
> think people may find it interesting. Second, I have technical
> concerns/questions about the implementation. There are a number of aspects
> of the implementation that feel too hacky to me. There is also functionality
> not possible with Mercurial today (mainly due to the wire protocol design).
> I'd like to have a discussion about supporting these use cases in a future
> Mercurial release. Notably:
>
> * Client doesn't self-advertise capabilities like servers do. It would be
> cool if servers could proactively sniff for missing capabilities and be like
> "upgrade your Mercurial install!"
>
> * Passing messages for user display from server to client is not well
> supported. Only some commands have their output sent to the client. I would
> like a dedicated "band" in the protocol for transporting messages back to
> clients for *any* command. I think allowing servers to "advertise" message
> of the day or such on pull could be very useful.
>
> * Possibly a superset of the above - it's not possible to exchange arbitrary
> metadata as part of client-server communication. My extension would be much,
> much easier if every command request and response could have arbitrary
> (key-value?) metadata attached to it.
>
> Is there any interesting in pursuing these features? Do people think my
> extension has wheels?
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=941856
>
> Gregory Szorc
> gregory.szorc at gmail.com

This is very cool. I currently maintain the projrc extension which is
somewhat related to this and I think the combination of this extension
with projrc may be very powerful (specially on a corporate
environment).

I have always felt that the biggest problem with the projr extension,
other than it not being bundled (yet?) with mercurial, is that in
order to be really useful it must be enabled and configured on every
client. It seems that your extension may fix that problem.

Cheers,

Angel