Patchwork & patch handling improvements

Trevor Woerner

Hi Richard,

On 12/02/15 03:44, Richard Purdie wrote:
On Mon, 2015-11-30 at 10:19 -0500, Trevor Woerner wrote:
A while back I had the idea of "porting" the kernel's "" to
The Yocto Project (it was around the same time that I was trying to
float the whole "Maintainers File" idea too, since I was also trying to
re-purpose "" as well).

The maintainers file is a different problem and its one of maintenance,
and more specifically what being listed means, who can be listed, how
that listing can be changed and so on. The Yocto Project has some notion
of maintainer and there its easy, Ross and I can made decisions on who
is listed and what those people are expected to do and we can make it
work (its how we ensure things get upgraded with some regularity). For
OE, who would do this and what would the maintainer file mean? If
someone patches something, are they required to cc the maintainer on
patches for example? (that would imply workflow overhead) What if they
don't cc a maintainer? Should we be forced to revert such a patch?
I didn't mean to bring up old discussions :-) All I was trying to say is
that one day I had the idea that it would be nice if we had something
similar to the kernel's and In my mind
all I was trying to do was to make it easier for people to:

a) submit good patches ( and
b) easier to get people to review patches (

Sending good patches: I went looking for a concise description of the
accepted recipe file format, poked around on the mailing list and on the
web, then found the two camps who had their own styles. In the end I
gave up on this. I'm excited about Paul's proposal and hopes it goes
well. Maybe we can convince people to put this script in their
~/.gitconfig's so it gets called automatically!

On reviewing patches: the kernel's get-maintainer script uses a bunch of
sources to try to put together a list of people who might be interested
in your patch (which can be used as a CC list for your email
submission). First off it looks for a MAINTAINERS file, parses it, and
figures out the people who are signed up for whatever things your patch
affects. Secondly, it looks at the exact lines of whatever files your
patch touches and looks through the revision history for those lines to
see who last touched them. It then concatenates these two groups
together and suggests these people as possible CC's when you email your

Personally I have my ~/.gitconfig configured such that this happens
automatically every time I invoke "git send-email". All I do is "git
send-email --identity=<repository> <patches...>" and my own
"" script gets invoked via the "cccmd" option. Then
my patch gets sent to the correct mailing list and also to the list of
people who are most likely to be interested in reviewing it.

I had never thought of, heard of, or considered the possibility that a
MAINTAINERS file could be meant for anything other than as input to the
get-list-of-cc-people script :-) And frankly, my
script runs perfectly fine without a MAINTAINERS file. It's just that
sometimes the maintainer isn't actually the person who last touched
whatever part of whatever file you're patching, and the script isn't
psychic (yet) ;-)