Re: [Ksummit-discuss] [RFC PATCH 2/3] MAINTAINERS, Handbook: Subsystem Profile

Em Fri, 16 Nov 2018 10:57:14 -0800 Dan Williams <dan.j.williams(a)intel.com&gt; escreveu: > On Fri, Nov 16, 2018 at 4:04 AM Mauro Carvalho Chehab > <mchehab(a)kernel.org&gt; 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.

> > > > +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).

> > > > +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.

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.