contribution process

[Augie Fackler]

On Jul 2, 2014, at 3:33 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> The arguments I've heard are that:
> 
> * Overhead to setting up SMTP server is high.

Yeah, this has annoyed me at times. A proposal I don't have the time to tackle that the moment:

patchbomb-as-a-service: you give it a URL to pull from and a sha1 to email, and it pulls, emails you for confirmation (as anti-spam), then when you click the confirmation link in your email it sends the patchbomb thread for you, with you cc'ed so you get responses from the list.

Would that help here?

> * If you're using a non-IMAP/POP client, importing patches can be harder.

I know marmoute is working on this - it's a pain point for some of the reviewers.

> * The "single place to look" for the currently under review patches
> is clearer for pull requests.

Also kind of working on this: see http://patchwork.serpentine.com/ and http://hgpatches.durin42.com - I'm trying to automate keeping patchwork at least vaguely correct, and the hgpatches link sniffs the list traffic to try and make things clearer.

I'm not opposed to improving this (really!), but it's a hard road to get something that'll make me (and more importantly mpm) productive. See http://patchwork.serpentine.com/patch/4978/ for details on why mpm gets frustrated.

(I don't disagree that it's a bummer email is what mpm is heavily optimized around, but OTOH I feel his pain acutely every time I try to work with someone using PRs on one of my smaller projects.)
-------------- 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/8a742482/attachment.asc>