contribution process

[cowwoc]

I agree with Paul here, it seems like a waste to lose contributors by 
making them jump through arbitrary hoops (configuring an email system).

Also, http://mercurial.selenic.com/wiki/ContributingChanges reads 
"Because this is a community project and our developers are very busy, 
patches will sometimes fall through the cracks. If you've gotten*no 
response*to your patch after a few days, feel free to resend it."

This is a process smell to me. A process that allows issues to fall 
through the cracks (as emails do, even outside the scope of Mercurial) 
is problematic. This is precisely one of the strengths of PRs: they 
integrate patches with the bug tracker in a way that ensures issues do 
not fall through the cracks.

I understand that Augie and mpm have issues with PRs but I see no reason 
why we couldn't get the PR system to cater to their needs (using 
webhooks as Paul said). Let's make this happen.

Gili

On 02/07/2014 3:39 PM, Alumni - pnathan wrote:
> Snips and inline.
>
>
> """
> I'd really like to chase down /what/ about patches-by-email is perceived to be awful. Right now I'm only hearing that y'all hate it, but not WHY.
>
>> I understand your reluctant to rely on non-OSS services, but I think people would benefit greatly from a better-organized, more visual contribution process as Github-style pull requests provide. I'm not asking you to stop accepting patches through the mailing list, but rather suggesting that accepting pull requests off Bitbucket would be a major step in the right direction.
>
> I've already stated how frustrating PRs are, both on BB and GH. That being a contribution mechanism for hg wouldn't be likely to get love from me or mpm, and I suspect the other reviewers would also not be fans of doing reviews there.
>
> """
>
> --- I have no interest in configuring my email system to send patches out. Its usually a hassle whenever I have to set up a new email client (which is designed to do email). convincing hg to do it will also be a hassle.   using hg itself, i.e,  "hg push bug-id" to push a new branch would be extremely simple. a web UI for pull requests and review is also useful. Much better than "see patch come through, comment on it, get new patch, have no idea what's different, watch the patch get split! and still have no diffability.".   my SCM is not an email client and shouldn't be doing that.
>
>
> --- hg team has pruned itself to only consist of people OK to happy with mailing list based workflows. I (and many others through the years) have expressed their displeasure with it. I find github pull requests to be *excellent* and to generally move towards implementing them in corporate environments.  If you demand all contributors to adapt to mailing list interface, you gate out people who won't touch it. Which is basically our point. It's become a non-standard and a hassle to do for people who haven't already configured their systems to do this.    If you are happy with current contributor level and patch frequency, there is no need to change. If you want more contributors, then something has to change.  As right now the change is towards git and web UIs, consider opening your gates to more people by moving to Bitbucket as the development truth.
>
> Regards,
> Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140702/04b39836/attachment-0002.html>