[plug] Kernel development process

Andrew Cooks acooks at gmail.com
Thu Jul 12 16:47:24 WST 2012

On Thu, Jul 12, 2012 at 3:08 PM, Daniel Hartwig <mandyke at gmail.com> wrote:
> On 12 July 2012 13:42, Andrew Cooks <acooks at gmail.com> wrote:
>> Hi List
>> Can someone explain to me why the kernel patch submission
>> process still involves sending patch-sets via email, instead
>> of just saying:
>> "Here's a new feature that does <something...>. You can fetch
>> it from <publicly accessible git repo/tag>, which is based on
>> <upstream version>."
> Hello
> Some reasons in support of submission via the mailing list:
> - avoids the potential inconvenience of setting up a publicly
> accessible repository;
> - easier to inspect than interfacing with multiple different
> repositories for small changes;
> - trivial to process offline for those who already read their mail offline;
> - ensures a more permanent record of submissions than any privately
> controlled repository could;
> - …
>> Is the issue that people shouldn't be forced to use git? Are
>> the existing tools for dealing with emailed patches really
>> better and if so, what are they?
> Git is still very much used, by most contributors anyway.  Excluding
> the reasons mentioned above, there is not really any convenience lost
> or gained by using email- versus repository-submission.
> The emailed patch sets are generated by git-format-patch(1), and
> subsequently merged with git-am(1).  These patch sets contain the full
> details of the relevant commits and the result is no different to
> using git-merge(1) instead.

Thanks, that really helps me make sense of it. It also partly explains
why some people have suggested that Gerrit might be useful (see
http://code.google.com/p/gerrit/ and

I'm trying to think of a way to deal with the volume of mail the lists
get. I'd like to ignore submissions of 27-part patches that aren't
relevant to me and the general tsunami of mail when the merge window
opens, while keeping track of some specific bits. Any ideas on that?


More information about the plug mailing list