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

[Michael Adam]

On 2015-02-14 at 17:51 +0100, Jelmer Vernooij wrote:
> On Fri, Feb 13, 2015 at 09:24:28PM +0100, Michael Adam wrote:
> > Summing up, I don't really see any advantage at alli
> > of any solution over the approach of:
> > 
> >   a single mail with
> >   a single attachment for
> >   a single patchset
> > 
> > Maybe I am missing something.
> > 
> > I don't really want to force a decision at this point
> > but request for comments, maybe I can understand what
> > rides poeple to submit patchsets in a potentially
> > mind-boggling number of mails. :-)
> 
> Yeah, that's a good point. I appreciate it's quite a flood of
> e-mails to the list.
> 
> 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. ;-)

> 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

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

>  * allows for easier cherry-picking by whomever applies the patches

Hmm, I don't understand what you mean by that:
My general assumption is that when someone submits
a patchset of 2 or 10 or 50 patches, that these patches
form a unit and it only makes sense to apply all or none
of them.

> git send-email does give you the ability to include a preamble with
> a patch set, but I hadn't done that in this case.

Yeah, it does improve things somewhat.

> When saving entire patchsets for applying in mutt, I tag all
> emails in a thread (ESC-t), possibly untag a few I don't like
> and then save them to a mailbox (";" to operate on all messages,
> then "s" to save to a mailbox). This is about as many keystrokes as it
> takes to save an attachment to disk in mutt. :)

Ok, for the _first_ incanation of the patchset at least.
If some of the patches have received updates, things
become more complicated. If you always send the
complete patchset in one file (tar or mbox), the
process is uniformly simple.

> In the case of this patch set, I merely cc'ed the mailing list in case
> anybody had comments (the main recipient was Andrew). Personally I
> don't mind the extra noise from patch discussions, but if people
> prefer I can also just avoid cc'ing the list for non-controversial
> patch sets like this one.

Ok, this is precisely not the kind of reaction I wanted
to provoke with my initial mail!

Please keep sending your patches in any form you prefer.
And please do keep sending them to the list. Please do
try to send a preamble. In that you could include an
indication that this is e.g. targeted to Andrew, etc.
Otherwise it is sometimes more difficult to make initial
sense of a big patchset.

I mostly wanted to express my preferences and reasons
and thanks everyone for sharing their thoughts!

Let me also repeat Simo's remark: A link to a private
git url with a branch containing the patchset is also
for me the most easy means of applying many patches.

Thanks - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150215/828a6fa2/attachment.pgp>