On 2023-10-16 11:08, Matthew Brost wrote: > On Fri, Oct 13, 2023 at 01:45:08PM -0400, Luben Tuikov wrote: >> On 2023-10-11 19:58, Matthew Brost wrote: >>> Rather than a global modparam for scheduling policy, move the scheduling >>> policy to scheduler so user can control each scheduler policy. >>> >>> v2: >>> - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben) >>> - Only include policy in scheduler (Luben) >>> v3: >>> - use a ternary operator as opposed to an if-control (Luben) >>> - s/DRM_SCHED_POLICY_DEFAULT/DRM_SCHED_POLICY_UNSET/ (Luben) >>> - s/default_drm_sched_policy/drm_sched_policy_default/ (Luben) >>> - Update commit message (Boris) >>> - Fix v3d build (CI) >>> - s/bad_policies/drm_sched_policy_mismatch/ (Luben) >>> - Don't update modparam doc (Luben) >>> v4: >>> - Fix alignment in msm_ringbuffer_new (Luben / checkpatch) >>> >>> Reviewed-by: Luben Tuikov <luben.tuikov@xxxxxxx> >>> Signed-off-by: Matthew Brost <matthew.brost@xxxxxxxxx> >> >> Hi, >> >> Forgot to mention this, but it is a very important process to note, >> is that one should _never_ add someone else's R-V tag, _*UNLESS*_ >> a) there's an email from the person giving their review or ack, and >> b) you're the one pushing the patch set into the tree. >> If you're not the one pushing it into the tree, the maintainer will >> add their R-V (after their reply-to follow-up email--see below), >> including a Link: tag when they do "git am" after it's been all reviewed. >> >> And there's a reason for this. >> >> The reason is that when kernel maintainers (especially DRM via dim[1]) push >> patches into the kernel, we want to add a Link: tag [2,3] pointing to >> the thread where a) the patch was posted and b) where the reviewer gave >> their Reviewed-by to the patch in a reply-all email, and at this moment >> there is no such email for this patch. >> >> When a maintainer says "Do X, Y, Z, for an immediate R-V", this means >> do those things, post it, and get a reply from the maintainer with an >> R-V. This records how it happened and is very helpful when doing >> data mining on how and why the code changed, via what patches, etc. >> >> I suspect there might be a v6, and we can do the R-V/Ack the right way >> at that time. No big deal, but it's good to know in one place as it >> is a bit scatter here and there in the kernel-doc. >> >> [1] https://gitlab.freedesktop.org/drm/maintainer-tools/ >> [2] git am --message-id >> [3] https://docs.kernel.org/maintainer/ >> -- >> Regards, >> Luben >> > > Again thanks for all the details of the development flow. Will read up > on all of this. > > Just to be to clear, when I post a rev6 I should not include a RB in the > patches that recieved an RB in rev5 (or prior revs)? Rather a Cc would > be better to alert the reviewer of another rev? If you've received an R-B in an email and are subsequently reposting the patch, append the R-B at the bottom of the tags, as a tool would do it. As for Cc: tags, I never separate --to/--cc/Cc:. I just include everyone in a Cc: tag, and my --to is just amdgfx or dri-dev. This way I don't need to worry about cc-s and what not--it's all in the commit message. It makes it easy for me, but you can do it whichever way is easier for you. As to Cc field, if I want someone to see my email, I always Cc them, else the rules put the email in some folder, where it may not be seen. But if their email is in the Cc or To field, then I know they'll get it in their inbox. -- Regards, Luben
