Re: [Qemu-arm] [Qemu devel PATCH] MAINTAINERS: Add entries for Smartfusion2

[Peter Maydell]

On 10 November 2017 at 00:22, Philippe Mathieu-Daudé <address@hidden> wrote:
> On 11/09/2017 08:55 PM, Peter Maydell wrote:
>> I don't in general expect to take pull requests from
>> everybody listed as a maintainer in the MAINTAINERS file.
>> That just means "I'm going to be reviewing and should
>> be cc'd on patches". Pull requests are sent by people
>> who are maintainers for a subsystem. Rule of thumb:
>> unless somebody asks you to send a pull request, you
>> don't need to do it.
>
> Ok, please apologize my misunderstanding. I still think the M: entry
> stand for 'Maintainer' instead of 'Mail', and still don't understand the
> difference with a "Designated reviewer" (R: entry):
>
>         M: Mail patches to: FullName <address@hidden>
>         R: Designated reviewer: FullName <address@hidden>
>            These reviewers should be CCed on patches.
>
> "Designated reviewer" seems to duplicate the M: entry and is therefore
> confusing. Can we simply remove it instead?

I hadn't realized we had an 'R:' tag in MAINTAINERS...

> --
> Some people are not content with the amount of mail they get, and would
> like to be CCed on patches for areas they do not maintain.  Let them
> satisfy their own appetite for qemu-devel messages.
>
> Seriously: the purpose here is a bit different from the Linux kernel.
> While Linux uses "R" to designate non-maintainers for reviewing patches
> in a given area, in QEMU I would also like to use "R" so that people can
> delegate sending pull requests while keeping some degree of oversight.
> --

So, my view, based on what happens in practice:
 * "maintainer" means you are in effect accepting some responsibility
   for the continued maintenance of some bit of the codebase, ie
   you actually will review stuff
 * "reviewer" is a bit weird but I guess is just asking for cc:
   without promising to actually do anything
 * somebody who sends me pull requests is effectively somebody we've
   given the ability to make direct more-or-less unchecked commits
   to master, so that is given out more sparingly and for larger
   subsystems

But MAINTAINERS is mostly about what submitters need to do (ie
who to send patchmails to), so it doesn't particularly document
how patches flow onward into master, which varies. (For instance
the block layer folks have a two-level setup where some trees
get merged into others before they go to master. ARM devboards
go through me, and "maintainer" just means I let somebody else
deal with the device specifics if possible but am still the
reviewer of last resort.)

thanks
-- PMM