On Thu, 15 Nov 2018 10:46:21 -0600 Eric Blake <ebl...@redhat.com> wrote:
> On 11/15/18 10:20 AM, Cornelia Huck wrote: > > On Fri, 26 Oct 2018 12:57:11 +0200 > > Cornelia Huck <coh...@redhat.com> 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 <coh...@redhat.com> > >> --- > >> > >> 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@domain> > >> + 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@domain> > >> 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?
