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

[Jelmer Vernooij]

On Fri, Feb 13, 2015 at 09:24:28PM +0100, Michael Adam wrote:
> I personally find the mode of sending one patch per
> mail instead of sending one patchset per mail somewhere
> between very difficult to cope with and unbearable,
> so that I generally try to stay away from bigger
> patchsets submitted like this for several reasons.
> 
> I want to elaborate on these reasons here not to address
> especially you but the whole team and community to
> get some feedback.
> 
> - You don't automatically get a introduction what the
>   overall patchset is all about (e.g. in your case.
>   what is its purpose?)
>   If you do it like I've seen David do, you get a
>   Patch 0/X mail with the initial explanation, that
>   fixes at least this thing.
> 
> - If people start replying to individual mails
>   and individual patches get updated, it quickly
>   gets almost impossible to know what the current
>   state of the patchset overall is.
> 
>   Also modifying one patch frequently requires
>   changing dependent patchest - where in the thread
>   do you post such updates?...
> 
> - How do I actually get the patches applied to my
>   git tree? I have to tag all relevant messages,
>   copy them into a new mbox file folder and use
>   that to do git am (for all I know).
> 
>   If I instead do "git format-patch --stdout" to
>   produce my patchset and attach that to a mail, it
>   just takes saving an attachment and applying it with
>   git am (provided I have set up encoding for
>   attachments correctly in my mail program ;-).
> 
> - Last but not least it complelety floods
>   the mailing list. Should we agree to require sending
>   one patch per mail, I would vote to create a separate
>   mailing list for patches. But imho it would be a bad
>   thing to separate the patches from the genenral
>   dev discussion.
> 
> So I would really really appreciate if people send
> patchsets in a single mail. There are (at least)
> two ways to do that:
> 
> 1) Do git format-patch HASH1^..HASH2
>    and attach all patch files produced to
>    a mail with a meaningful intro to the patchset.
> 
> 2) Do git format-patch --stdout HASH1^..HASH2 > my.patches
>    and attach my.patches to a mail with a meaningful
>    intro to the patchset.
> 
> Of these I greatly favour number 2, since for variant 1
> you again have the problem of saving and applying 55 single
> patch files, so let's forget about #1.
> 
> A viable variant of #1 could be to create a tar
> archive of the individual patch files and attach those.
> But the creation process is made more elaborate.
> 
> 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'.

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
 * allows for easier cherry-picking by whomever applies the patches

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.

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

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.

Cheers,

Jelmer

> On 2015-02-06 at 20:03 +0100, Jelmer Vernooij wrote:
> > This is a short module (< 1k lines) that removes the need to
> > depend on subunit, testtools, extras and mimeparse. It is
> > based on an extract from testtools and subunit.
> > 
> > Change-Id: I0a4f3060b25f7bde602a07ed6bef71c8196fca64
> > Signed-Off-By: Jelmer Vernooij <jelmer at samba.org>
> > ---
> >  python/samba/subunit/__init__.py |   0
> >  python/samba/subunit/run.py      | 750 +++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 750 insertions(+)
> >  create mode 100644 python/samba/subunit/__init__.py
> >  create mode 100755 python/samba/subunit/run.py
> > 
> -------------- 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/20150213/d1abee7d/attachment.pgp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150214/d508ad02/attachment.pgp>