From: Dan Williams <dan.j.williams@intel.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Vishal L Verma <vishal.l.verma@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dmitry Vyukov <dvyukov@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
stfrench@microsoft.com, "Tobin C. Harding" <me@tobin.cc>
Subject: Re: [Ksummit-discuss] [RFC PATCH 2/3] MAINTAINERS, Handbook: Subsystem Profile
Date: Sun, 18 Nov 2018 09:31:18 -0800 [thread overview]
Message-ID: <CAPcyv4hX_B5HZ8Cj8VmjeeteZVkn-Ax8avAcUwUQqzH6J67ryA@mail.gmail.com> (raw)
In-Reply-To: <20181118105829.7388cc7d@coco.lan>
On Sun, Nov 18, 2018 at 4:58 AM Mauro Carvalho Chehab
<mchehab@kernel.org> wrote:
>
> Em Fri, 16 Nov 2018 10:57:14 -0800
> Dan Williams <dan.j.williams@intel.com> escreveu:
> > On Fri, Nov 16, 2018 at 4:04 AM Mauro Carvalho Chehab
> > <mchehab@kernel.org> wrote:
[..]
> > Yes. Maybe a "Review Forum" section for subsystems that have
> > transitioned from email to a web-based tool? There's also the
> > exception of security disclosures, but the expectations for those
> > patches are already documented.
>
> Maybe. I would postpone adding a section like that until some
> subsystem maintainer that actually changed to Github/Gitlab
> would submit his subsystem profile.
Sure.
> > > > > +Last -rc for new feature submissions
[..]
> > > This is a general ruleset that describes the usual behavior, telling the
> > > developers the expected behavior. If the maintainers can do more on some
> > > particular development cycle, it should be fine.
> >
> > Yes, and perhaps I should clarify that this is the point at which a
> > maintainer will start to push back in the typical case, and indicate
> > to a contributor that they are standing in exceptional territory.
> > Similar to how later in the -rc series patches get increasing
> > scrutiny.
>
> Makes sense. There's one issue, though.
>
> I don't expect developers to read the profile template, as this is a
> material for the maintainer themselves. Developers should likely read
> just the specific subsystem profile for the patches that will be submitted.
>
> So, either each subsystem profile should have a reference to the
> profile template, or need to copy some "invariant" texts (with would be
> really painful to maintain).
Agree, a general link back to the handbook template for clarification
on any of the sections seems sufficient.
[..]
> > > > > +Trusted Reviewers
> > > > > +-----------------
> > > > > +While a maintainer / maintainer-team is expected to be reviewer of last
> > > > > +resort the review load is less onerous when distributed amongst
> > > > > +contributors and or a trusted set of individuals. This section is
> > > > > +distinct from the R: tag (Designated Reviewer). Whereas R: identifies
> > > > > +reviewers that should always be copied on a patch submission, the
> > > > > +trusted reviewers here are individuals contributors can reach out to if
> > > > > +a few 'Resubmit Cadence' intervals have gone by without maintainer
> > > > > +action, or to otherwise consult for advice.
> > > >
> > > > This seems redundant with the MAINTAINERS reviewers list. It seems like
> > > > the role specified in this section is more of an ombudsman or developer
> > > > advocate who can assist with the review and/or accept flow if the
> > > > maintainer is being slow to respond.
> > >
> > > Well, on subsystems that have sub-maintainers, there's no way to point to
> > > it at MAINTAINERS file.
> > >
> > > Also, not sure about others, but I usually avoid touching at existing
> > > MAINTAINERS file entries. This is a file that everyone touches, so it
> > > has higher chances of conflicts.
> > >
> > > Also, at least on media, we have 5 different API sets (digital TV, V4L2, CEC,
> > > media controller, remote controller). Yet, all drivers are stored at the
> > > same place (as a single driver may use multiple APIs).
> > >
> > > The reviewers for each API set are different. There isn't a good way
> > > to explain that inside a MAINTANERS file.
> >
> > Would it be worthwhile to have separate Subsystem Profiles for those
> > API reviewers? If they end up merging patches and sending them
> > upstream might we need a hierarchy of profiles for each hop along the
> > upstream merge path?
>
> I guess having hierarchical profiles will make it very confusing.
> The point is: inside a subsystem, the same ruleset usually applies to
> everything.
Ok.
> In the case of media, it is not uncommon to have patches that require
> multiple APIs. Consider, for example, a SoC used on a TV box. The driver
> itself should be placed at drivers/media/platform/, but it will end by
> being a bunch of sub-drivers that together will add support for V4L,
> Digital TV, remote controller, CEC and codecs, and need to be controlled
> via the media controller API. It may even have camera sensors.
>
> On other words, all media APIs will be used (after having it fully
> sent upstream).
>
> In practice, drivers for complex hardware like that is submitted in
> parts. For example, one SoC vendor started sending us the remote
> controller driver (as it would be the simplest one).
>
> The only part of the policy that changes, depending of what API
> is involved, is the one that will do the review.
>
> As the driver itself will be at the same place, no matter what APIs
> are used, get_maintainers.pl is not capable of identifying who are
> the reviewers based "F:" tags[1].
>
> [1] It could be possible to teach get_maintainers to better hint it,
> by making it look who are the reviewers for the headers that are
> included.
>
> >
> > > > > +Time Zone / Office Hours
> > > > > +------------------------
> > > > > +Let contributors know the time of day when one or more maintainers are
> > > > > +usually actively monitoring the mailing list.
> > > >
> > > > I would strike "actively monitoring the mailing list". To me, it should
> > > > be what are the hours of the day that the maintainer might happen to poll
> > > > (or might receive an interrupt) from the appropriate communications
> > > > channels (could be IRC, could be email, etc).
> >
> > Yes, makes sense.
> >
> > > > For my area, I would want to say something like: I tend to be active
> > > > between 17:00 UTC (18:00 UTC when daylight savings) and 25:00 (26:00),
> > > > but often will check for urgent or brief items up until 07:00 (08:00).
> > > > I interact with email via a poll model. I interact with IRC via a
> > > > pull model and often overlook IRC activity for multiple days).
> > >
> > > Frankly, for media, I don't think that working hours makes sense. Media
> > > (sub-)maintainers are spread around the globe, on different time zones
> > > (in US, Brazil and Europe). We also have several active developers in
> > > Japan, so we may end by having some day reviewers/sub-maintainers from
> > > there.
> >
> > For that case just say:
> >
> > "the sun never sets on the media subsystem" ;-)
>
> :-)
>
> >
> > > At max, we can say that we won't warrant to patches on weekends or holidays.
> >
> > Yeah, maybe:
> >
> > "outside of weekends or holidays there's usually a maintainer or
> > reviewer monitoring the mailing list"
>
> Well, 24/7, there is always patchwork monitoring the ML and picking
> the patches. When the patch will be handled by someone is a different
> question. As it is a high-traffic subsystem with an even higher ML
> traffic, each sub-maintainer have its own policy about when they
> review patches (usually one or twice per week - as most maintainers
> are also active developers, and don't want to mix their development
> time with reviewing time).
>
> I'm not quite sure about what you expect with this specific part of
> the profile.
>
> I mean: why a submitter should care about office hours?
>
> Also, people may be OOT during some period of time, or working
> remotely from some other office.
>
> Except if the idea would be to point to some site that would
> dynamically track each maintainer's weekly maintainership
> window (with would be a real pain to keep updated), I guess this
> is useless.
True, will remove. What's the point of stating daily active hours when
we already have "Resubmit Cadence" (I think I'll rename it "Follow
Cadence") measured in multiple days / weeks.
next prev parent reply other threads:[~2018-11-18 17:31 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 4:53 [RFC PATCH 0/3] Maintainer Handbook: Subsystem Profile Dan Williams
2018-11-15 4:53 ` [RFC PATCH 1/3] MAINTAINERS: Reclaim the P: tag for " Dan Williams
2018-11-15 5:39 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2018-11-15 20:12 ` Joe Perches
2018-11-15 4:53 ` [RFC PATCH 2/3] MAINTAINERS, Handbook: " Dan Williams
2018-11-15 5:48 ` [Ksummit-discuss] " Julia Lawall
2018-11-15 7:59 ` Geert Uytterhoeven
2018-11-15 13:47 ` Julia Lawall
2018-11-16 12:44 ` Jani Nikula
2018-11-16 17:56 ` Joe Perches
2018-11-17 14:12 ` Rob Herring
2018-11-17 17:03 ` Julia Lawall
2018-11-20 7:28 ` Jani Nikula
2018-11-15 5:49 ` Mauro Carvalho Chehab
2018-11-15 7:58 ` Geert Uytterhoeven
2018-11-15 8:38 ` Jani Nikula
2018-11-15 18:03 ` Tim.Bird
2018-11-15 23:56 ` Tobin C. Harding
2018-11-15 15:44 ` Mauro Carvalho Chehab
2018-11-16 23:28 ` Randy Dunlap
2018-11-17 11:57 ` Hans Verkuil
2018-11-16 0:11 ` Frank Rowand
2018-11-16 12:04 ` Mauro Carvalho Chehab
2018-11-16 18:57 ` Dan Williams
2018-11-18 12:58 ` Mauro Carvalho Chehab
2018-11-18 17:31 ` Dan Williams [this message]
2018-11-18 17:31 ` Dan Williams
2018-11-18 17:34 ` Dan Williams
2018-11-18 17:44 ` Mauro Carvalho Chehab
2018-11-16 16:47 ` Frank Rowand
2018-11-15 4:53 ` [RFC PATCH 3/3] libnvdimm, MAINTAINERS: " Dan Williams
2018-11-15 8:03 ` [Ksummit-discuss] " Geert Uytterhoeven
2018-11-15 14:10 ` Mauro Carvalho Chehab
2018-11-15 16:20 ` Leon Romanovsky
2018-11-15 19:09 ` Mauro Carvalho Chehab
2018-11-15 19:35 ` Leon Romanovsky
2018-11-15 19:40 ` Luck, Tony
2018-11-15 19:43 ` Joe Perches
2018-11-16 11:39 ` Mauro Carvalho Chehab
2018-11-18 7:12 ` Leon Romanovsky
2018-11-16 11:33 ` Mauro Carvalho Chehab
2018-11-16 12:00 ` Jan Kara
2018-11-18 7:00 ` Leon Romanovsky
2018-11-16 20:36 ` Rodrigo Vivi
2018-11-16 23:44 ` Dan Williams
2018-11-17 0:38 ` NeilBrown
2018-11-18 13:11 ` Mauro Carvalho Chehab
2018-11-18 13:03 ` Mauro Carvalho Chehab
2018-11-20 8:10 ` Jani Nikula
2018-11-20 19:31 ` Dan Williams
2018-11-26 11:12 ` Mauro Carvalho Chehab
2018-11-26 15:55 ` Joe Perches
2018-11-16 19:13 ` Dan Williams
2018-11-15 14:30 ` Mauro Carvalho Chehab
2018-11-15 14:51 ` Julia Lawall
2018-11-16 19:20 ` Dan Williams
2018-11-16 2:58 ` y-goto
2018-11-17 0:32 ` [Ksummit-discuss] " David Woodhouse
2018-11-15 5:56 ` [RFC PATCH 0/3] Maintainer Handbook: " Mauro Carvalho Chehab
2018-11-25 10:57 ` Pavel Machek
2018-11-25 20:55 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPcyv4hX_B5HZ8Cj8VmjeeteZVkn-Ax8avAcUwUQqzH6J67ryA@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=dvyukov@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mchehab@kernel.org \
--cc=me@tobin.cc \
--cc=stfrench@microsoft.com \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).