Re: [Qemu-devel] [PATCH RFC] MAINTAINERS: clarify some of the tags

[Cornelia Huck]

On Thu, 15 Nov 2018 10:46:21 -0600
Eric Blake <address@hidden> wrote:

> On 11/15/18 10:20 AM, Cornelia Huck wrote:
> > On Fri, 26 Oct 2018 12:57:11 +0200
> > Cornelia Huck <address@hidden> wrote:
> >   
> >> The MAINTAINERS file is a bit sparse on information about what
> >> the different designators are. Let's add some more information
> >> to give contributors a better idea about what the different
> >> roles are.
> >>
> >> Signed-off-by: Cornelia Huck <address@hidden>
> >> ---
> >>
> >> This came out of a discussion about what being a 'reviewer' listed in
> >> this file actually means. A reviewer probably should already have a
> >> track record of doing helpful reviews before being listed in here.
> >>
> >> While at it, I also tried to add some more hints for the other entries.
> >> This patch is supposed to be a starting point for further discussion.  
> > 
> > Ping. Further discussion would be good :)  
> 
> Recent threads have mentioned the possibility of potentially adding a 
> new category P: for the person that submits pull requests, although I'm 
> not quite sure how that is different from M: as a maintainer

Let's wait how that discussion turns out (I'm not quite sure about the
semantics, either.) We can document it then.

> 
> >> +++ b/MAINTAINERS
> >> @@ -12,9 +12,14 @@ consult qemu-devel and not any specific individual 
> >> privately.
> >>   Descriptions of section entries:
> >>   
> >>    M: Mail patches to: FullName <address@hidden>
> >> +     Maintainers are looking after a certain area and must be CCed on
> >> +     patches. They are considered the main contact point.  
> 
> Maybe add something along the lines of "However, a maintainer may accept 
> code that has been reviewed by others without explicitly reviewing it 
> themselves"?

I'm not sure whether that adds vital information. If a maintainer picks
a patch that has been reviewed by others, they may or may not do a
proper review themselves; but the end result is basically the same
(patch makes its way into the tree.)

> 
> >>    R: Designated reviewer: FullName <address@hidden>
> >>       These reviewers should be CCed on patches.
> >> +     Reviewers are familiar with the subject matter and provide feedback
> >> +     even though they are not maintainers.
> >>    L: Mailing list that is relevant to this area
> >> +     These lists should be CCed on patches.
> >>    W: Web-page with status/info
> >>    Q: Patchwork web based patch tracking system site
> >>    T: SCM tree type and location.  Type is one of: git, hg, quilt, stgit.  
> >   
> 
> At any rate, I like the idea of adding the additional descriptions for 
> the categories, even if we still bike-shed on the wording or even the 
> set of categories to use.

What about going with this as a starting point?