On Tue, 09 Aug 2022, Krzysztof Kozlowski wrote: > On 09/08/2022 18:33, Lee Jones wrote: > > On Mon, 08 Aug 2022, Krzysztof Kozlowski wrote: > > > >> On 07/08/2022 17:52, Paul Cercueil wrote: > >>> Use the new DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros > >>> to handle the .suspend/.resume callbacks. > >>> > >>> These macros allow the suspend and resume functions to be automatically > >>> dropped by the compiler when CONFIG_SUSPEND is disabled, without having > >>> to use #ifdef guards. > >>> > >>> The advantage is then that these functions are now always compiled > >>> independently of any Kconfig option, and thanks to that bugs and > >>> regressions are easier to catch. > >>> > >>> Signed-off-by: Paul Cercueil <paul@xxxxxxxxxxxxxxx> > >>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > >>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx> > >> > >> The address does not work. Please don't add it to commit log. > >> > >>> Cc: linux-samsung-soc@xxxxxxxxxxxxxxx > >> > >> This is also not really needed in commit log... it's just a mailing list... > >> > >> I actually never understood why people want to add to commit log, so to > >> something which will last 10 years, Cc-ing other folks, instead of > >> adding such tags after '---'. Imagine 10 years from now: > >> > >> 1. What's the point to be cced on this patch after 10 years instead of > >> using maintainers file (the one in 10 years)? Why Cc-ing me in 10 years? > >> If I am a maintainer of this driver in that time, I will be C-ced based > >> on maintainers file. If I am not a maintainer in 10 years, why the heck > >> cc-ing me based on some 10-year old commit? Just because I was a > >> maintainer once, like 10 years ago? > > > > Why would that happen? > > > > These tags are only used during initial submission. > > No, the tags are used in any other resends, backports etc while > traveling through different trees. I think only stable-backports do not > use them, but all other gfp+git-send will follow the tags. > > > > >> 2. Or why cc-ing such people when backporting to stable? > > > > That doesn't happen either. > > Indeed, stable does not use these Cc. > > >> It's quite a lot of unnecessary emails which many of us won't actually > >> handle later... > >> > >> I sincerely admit I was once also adding such Cc-tags. But that time my > >> employer was counting lines-of-patch (including commit log)... crazy, right? > > > > Nothing wrong with adding these tags IMHO. It's what they're for. > > > > I use them when I'm maintaining a large amount of out-of-tree, but > > to-be-upstreamed patches over several versions. Re-applying the > > recipients list can become pretty labour-some after several > > iterations. > > You can do it still while keeping the tags after ---. Only patch-related > workflows strip such tags. If you cherry-pick, rebase, merge, you always > get the content of ---. > > The same as typical changelog (not cover letter but one in the patch) - > you keep it after --- and it does not disappear. I'll have to try this next time. > > Adding them under the '---' doesn't work when the purpose of them is > > to keep the recipients list in Git history. > > This I understand, what I did not understand (and you did not explain) > is what would be the purpose to keep them in Git history. What is the > point to have them in commit log of 10 year old commit? Here is a documented use for the tags: "If a person has had the opportunity to comment on a patch, but has not provided such comments, you may optionally add a ``Cc:`` tag to the patch." Thus, when a recipient replies with a *-by tag, I strip out the corresponding Cc: line. Obviously this does not apply to mailing lists. -- DEPRECATED: Please use lee@xxxxxxxxxx
