[RFC] Patchsets in a single mail? [Re: [PATCH 01/55] Add simple subunit runner outputting subunit v1.]

[David Disseldorp]

Hi Michael,

On Sun, 15 Feb 2015 11:02:08 +0100, Michael Adam wrote:

> > I am sending patches as individual emails mostly since that appears
> > to be the default mode of operation for git patch contributions.
> > This is how most other projects that use git patches by
> > e-mail do it, and it is the default behaviour of git tools like 'git
> > send-email'.  
> 
> Right. This assumes you want to use git send-email...
> In my very personal opininion git send-mail is just
> a mistake. Or at least always an emergency solution
> if someone can't use proper attachments.
> 
> It simply gives me the creeps that the mail transport
> path should tamper with my patches which are surely
> ripped apart (subject in hearder / rest of commit msg
> and patch in body...). With the attachment alternative
> the whole patch object is nicely isolated.
> But that is just my personal pranoia. ;-)

MITM fudging (by transport or otherwise) is possible in both cases. The
reviewer is evaluating the patch-set for inclusion base on what ends up
in his or her mailbox, so should catch this.

Simo's suggestion of simply referring to a (trusted) repository URL
would be the best way to avoid this IMO.

> > While this behaviour is quite spammy (especially when using small
> > commits, like in Samba), it also:
> > 
> >  * makes it easier to follow up on individual commits since you can
> >    just reply in-line  

I completely agree with Jelmer here.

The review process doesn't just involve getting the patch-set to the
reviewer, more importantly it allows for the reviewer to provide
feedback for the change, which IMO is best given alongside the context
of the actual code.

> Well, you can reply inline, too, if you attach the whole
> patchset to one email. It may require some more scrolling
> to get to the point though. :-)

Authors already go to the effort of breaking up changes into manageable
and reviewable commits, so it makes sense to provide feedback with the
same granularity.

Cheers, David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150215/1d73718c/attachment.pgp>