contribution process

[Augie Fackler]

On Jul 2, 2014, at 4:06 PM, cowwoc <cowwoc at bbs.darktech.org> wrote:

> 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 responded earlier in the thread to Matthew Turk with some links. Short version: yes, this is a problem, and we've got increasingly better tooling in patchwork and my robot that lets us notice things that fall through the cracks more reliably.

> 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.

If you've got time to spend on this, I'd be delighted! I'd even try and integrate it into the patch robot.

If you can, go look at my response to Matthew and see what you think of my patchbomb-as-a-service idea. If it exists, we can certainly find a place to host it.

Also, the robot's UI (http://hgpatches.durin42.com/) could definitely use some love. http://hg.durin42.com/patchbot/ is where the code lives, but I can put a mirror up on BB and try out PRs if people are willing to lend a hand.

Synchronizing through email is a drag, but it's (sadly) what we've got. *mumbles something about "wave was supposed to fix this"*

> 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.

I'd be happy to have more contributors, but only if we can handle the load. Right now, if everything moved to PRs, we'd be totally overwhelmed by the existing patch load.

>> 
>> Regards,
>> Paul
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140702/b6949830/attachment.asc>