About an IRC discussion on using pull requests for hg development

[Sean Farley]

On Wed, May 9, 2012 at 3:54 AM, Levi Bard <
taktaktaktaktaktaktaktaktaktak at gmail.com> wrote:

> >> > <mpm>
> >> > Every time this comes up, I say "but I do accept pull requests!"
> >> >
> >> > But I only want pull requests from people who have a track record of
> >> > getting a submission right the first time and have internalized
> >> > important rules like "don't mix unrelated changes". Otherwise I'll
> >> > start reading your incoming csets, discover problems, then ask you to
> >> > resend so I can comment on the problems. Which means my aborted first
> >> > pass was wasted effort.
>
> Why?
> If you want to have a hierarchy where incoming changes go through crew
> (or someplace) first, meaning that they're reviewed/accepted/merged by
> somebody that's not you, that's ok - but that's not what exists now.
> So, after creating a patch, my options are:
>  * Figure out wtf patchbomb is, argue with people for a while about
> whether I should really have to use it in 2012, trial/error until I
> get it configured correctly, send patch for review, receive comments,
> decide how to rework patch, figure out wtf mq is, ...
>  * GTFO
>
> This is not attractive to me as a new contributor.


[snip]


> Mercurial is of course not my project, and I'm far from being a
> regular contributor, but I see this enforced workflow hurting the
> project in three significant ways:
>  * High barrier to entry: it is significantly more hassle to submit a
> patch to mercurial than to any other project in my experience, with
> the possible exception of the Linux kernel. This discourages
> first-time and casual contributions.
>  * Vote of no confidence: the fact that a modern DVCS project handles
> internal contributions by emailing patches around doesn't project a
> lot of confidence in the tool itself. There is no technical reason
> that mercurial development could not actually be happening in CVS.
> Would you feel good about an IDE whose developers mainly used vim?
>  * Worms in the dogfood: I argue that core features of mercurial
> suffer from bugs, incompleteness, and "papercut" workflow issues,
> because the mercurial project itself doesn't use them. The two main
> examples I can see are subrepos and branches.


I'm not sure where this discussion is going but it seems that two ideas of
code review are emerging:

1) Changing the core mercurial workflow of mailing lists

2) Supporting some kind of code review in mercurial (?)

Could something like hg-review[1] (or similar) be used more within the
mercurial group (dog fooded) and on the list? Since hg-review is
very analogous to having a mq repo, it seems that some more love could be
given to the extension in the form of

a) integrating with mailing lists

b) tighter coupling with (the future) evolution changesets

c) integration with 'hg serve' and friends?

This would seem to appease the new-comers (not familiar with mq and
patchbomb) and the regulars (keeping things on the mailing list).

[1] http://sjl.bitbucket.org/hg-review/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120509/3ecb2175/attachment.html>