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