On 10 November 2017 at 00:22, Philippe Mathieu-Daudé <f4...@amsat.org> 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@domain> > R: Designated reviewer: FullName <address@domain> > 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