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

[Michael Adam]

Hi Jelmer,

apart from the fact that I am probably not the most
suitable review for this patchset, some general
comments, that actually don't even touch the actual
patches yet:

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

Thanks - Michael


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>