One more very important thing! Once you add an R-V tag, you cannot change the patch and keep the R-V, when reposting it. If you change the code and thus the patch changes, you _*must*_ remove the R-V tag, to let people know that there's changes which need reviewing. Regards, Luben On 2023-10-12 01:54, Luben Tuikov wrote: > On 2023-10-12 00:31, Matthew Brost wrote: >> On Wed, Oct 11, 2023 at 08:39:55PM -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> >>> >>> Was the R-V added by hand? (As in editing the commit message manually?) >>> >> >> Yes. >> >>> I use automated tools for this which do not re-order the tags. >>> IOW, the S-O-B is first as this is how it appears in the patch, >>> then the R-V most probably added by automated tools, and then >>> any other as are tacked on by other automated tools. >>> >> >> Ok, so always add tags in order starting with S-O-B? > > Yes! > > The S-O-B tag you add when you write the commit and then you post > it up to a mailing list, it's mandatory and it's always there. > It's most likely the first, top tag. > > Then various other scripts and tools start adding tags in an automated way, > and those tags are just appended below any existing tags. > > Generally, always follow a natural order (meaning least amount of energy > expenditure--if you have to edit to reorder, that is extra energy expenditure > and nature doesn't like that). Make it like a letter you'd get from or write to > your bank, attorney, etc. > These are tags you add when you craft your commit: > Cc: goes first, followed by other tags whose values > Cc: are personal emails, i.e. people. These are people > Cc: you want to let know of this commit. This is followed > Cc: by other personal tags, for instance, > Co-developed-by: or > Suggested-by: Another personal tag is, > Reported-by: which must be followed by a Link tag with > Link: the link of the report. This could also be a link to anything else. You can also add a > Fixes: tag which should follow a --pretty %h (\"%s\") format. > Closes: link to the bug the patch closes > Signed-off-by: You > Then scripts and tools (or even people) would append the tag list with: > Tested-by: someone reliable, could have more than one instance of this tag, > Acked-by: someone > Reviewed-by: someone > > There are no empty lines between tags. They form a block paragraph as they would > if/when added by a script. (I never add _any_ tag manually.) > > So, for instance, you may have: > > Cc: Luben > Signed-off-by: Matt > > And when the patch is R-V-ed this becomes (least amount of energy, append at the bottom), > > Cc: Luben > Signed-off-by: Matt > Reviewed-by: Luben > > Then other tags may be appended, depending on the path the patch takes to land in a tree. > > Check out: > https://docs.kernel.org/process/5.Posting.html > https://docs.kernel.org/process/submitting-patches.html > https://docs.kernel.org/process/submit-checklist.html > And there's more resources to check out in the Documentation/process directory.
