Please send patch series as patch series.  It is almost impossible to
keep track of a patch series as unrelated emails, even worse than the
other way around.

Please keep subjects to about 50 chars max., distinguishable in the
first 30 or so chars, so that patches can actually be found in mail
clients and in git --oneline logs and the like.

Please keep email bodies to <72 chars wide, just like commit messages
and changelogs are (excluding the leading tab for the latter).  You
cannot use the email message (or parts of it) as commit message
otherwise, and replying to your emails is harder than needed already.

Don't write irrelevant history of other patches in a patch message.

Don't write irrelevant history of other patches in a patch message.

In the subject write the core thing the patch does, and in the first
paragraph expand on that a bit.  Importantly, write *why* this is a
good thing to do.

If you make a series, the patches should be related.  Early in the
series patches are typically clean ups (that can go in separately, but
you need them for later patches), then you often have some stuff
making some infrastructure or utility functions or the like for later
patches, and then you get the meat of the matter, maybe followed by
some extra cleanups that now became possible (or that you just noticed
because of it, even).

Infrastructure additions or code rearrangement or similar stuff that
does not actually have any direct function, should always be followed
by other patches that make use of it.

When I get a patch, I read the message text.  If then I still have any
clue what the patch is about, I look if the patch actually does what it
was said to do.  I might refer to later patches in the series for that,
and also for the last step, which is to see if what the patch series
does is such a good idea at all.  If I cannot do these steps, it takes
hours more than needed to review every single patch.


Segher

Reply via email to