| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| mchehab | sailus: thanks for reviewing the glossary patchset! Just sent a new version addressing the points you mentioned
please check if my changes are ok, as my plan is to merge this series later today, after finish handling the pending PRs | [09:11] |
| ................................... (idle for 2h53mn) | ||
| hverkuil: ping
at this patch: add vb2_video_unregister_device helper function (from your git pull request) I noticed something weird at the comments: [hverkuil: improve the commit text] so, I'm in doubt: is this patch written by you (as indicated at the commit) or it was written by someone else, and somehow the "From:" got mangled somewhere? | [12:05] | |
| hverkuil | mchehab: it refers to the comments I got: https://patchwork.linuxtv.org/project/linux-media/patch/20200713113048.1150542-2-hverkuil-cisco@xs4all.nl/
So it is just a reference to the fixed typo. Probably overkill to add that line since I'm the author anyway. | [12:10] |
| mchehab | yep. OK then. Btw, the proper syntax for non-author comments is:
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] I guess sometimes you and sailus end forgetting to add your e-mail on it | [12:12] |
| hverkuil | Are you sure? Someone once told me that the username is enough. | [12:13] |
| mchehab | If you are a subsystem or branch maintainer, sometimes you need to slightly
modify patches you receive in order to merge them, because the code is not exactly the same in your tree and the submitters'. If you stick strictly to rule (c), you should ask the submitter to rediff, but this is a totally counter-productive waste of time and energy. Rule (b) allows you to adjust the code, but then it is very impolite to change one submitter's code and make him endorse your bugs. To solve this problem, it is recommended that you add a line between the last Signed-off-by header and yours, indicating the nature of your changes. While there is nothing mandatory about this, it seems like prepending the description with your mail and/or name, all enclosed in square brackets, is noticeable enough to make it obvious that you are responsible for last-minute changes. Example:: Signed-off-by: Random J Developer <random@developer.example.org> [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org> more Documentation/process/submitting-patches.rst Currently, there's no exception there, except for -stable maintainers | [12:13] |
| hverkuil | 'hverkuil@xs4all-cisco.nl' is quite long, so using 'hverkuil
'hverkuil@xs4all-cisco.nl' is quite long, so using 'hverkuil' only gives more room for the change description. | [12:14] |
| mchehab | hverkuil: well, mchehab+huawei@kernel.org is even bigger | [12:14] |
| hverkuil | If you prefer the full email, then I'll use that next time. | [12:15] |
| mchehab | ah, please don't kill the messager :-)
from my side, I would be OK with just "hverkuil", but we need to change Documentation/process/submitting-patches.rst for it to accept the alternate way I can only guess why the one who added it opted to have the full e-mail there... maybe someone might use scripts to grep for it - or maybe it needs some sort of way to uniquelly identify the author of a comment not sure in any case, the better is to stick to whatever is there | [12:15] |
| hverkuil | Looking at what others do in git log I see many who stick to the username only as well. | [12:19] |
| mchehab | at submitting-patches.rst
yeah, I've seen people doing that and even just [foo comment] yet, most of the time, I guess people follow the rule git log v5.0.. |grep '\[.*\@.*\]'|wc -l 1619 | [12:19] |
| hverkuil | of the 16814 [] lines in git log (approx) 9018 use an email address and 7796 just the username. | [12:22] |
| mchehab | well, there are lots of lines like "[0.1234]"
and sometimes: [foo@bar ... | [12:22] |
| hverkuil | git log|grep '^ Â Â Â \[[a-z].*:.*\]' >x | [12:23] |
| mchehab | ]
I'm seeing lots of: [why] $ git log --pretty=email v5.0.. |grep -E '\[[\w]\S+@\S+:\s+.*\]'|wc -l 17 $ git log --pretty=email v5.0.. |grep -E '\[[\w]\S+:\s+.*\]'|wc -l 111 ok this is more realistic, it seems only 15% are using the pattern specified at Documentation/process/submitting-patches.rst (well, the match doesn't cover multi-line comments) I end doing multi-line comments myself, due to the big size of my e-mail anyway, you win :-) I'll start accepting this pattern too wait a moment! almost all such logs come from someone called "will" removing this guy: $ git log --pretty=email v4.0.. |grep -E '\[[\w][^\s\@]+:\s+.*\]'|grep -v "will:"|wc -l 6 $ git log --pretty=email v4.0.. |grep -E '\[[\w]\S+@\S+:\s+.*'|wc -l 72 The stats are pretty much deviated due to "will" $ git log --pretty=email v4.0.. |grep -E '\[[\w][^\s\@]+:\s+.*\]'|grep -v "will:" [willy: fix printk warnings s/%lx/%x/g in sun_82077_fd_{inb,outb}()] [willy: minimal rewording of the commit message] [writeback: schedule periodic writeback with sysctl]. [wildea01: compile fixes for ll/sc] [willy: fix pfn_t_to_phys as well] [willy: symmetry fixups] gah! forget about that grep is not accepting "\w" | [12:23] |
| hverkuil | git log v4.0.. |grep '^ Â Â Â \[[a-z].*:.*\]'|grep -v '^ Â Â Â \[v[0-9]'|grep -v '\[will:' >x
$ grep '@' x|wc                                                                   3557   19467  218472 $ grep -v '@' x|wc                                                                4183   26020  214056 | [12:40] |
| mchehab | $ git log --pretty=email v4.0.. |grep -E '^\[[a-zA-Z]\S+@\S+:\s+.*'|wc -l
3880 $ git log --pretty=email v4.0.. |grep -E '^\[[a-zA-Z][^\s\@]+:\s+.*\]'|wc -l 3534 $ git log --pretty=email v4.0.. |grep -E '^\[[a-zA-Z][^\s\@]+:\s+.*'|wc -l 4070 yeah, 3880 comments followed submitting-patches.rst format, 4070 didn't followed (probably there are some false positives there - probably most of them affecting the grep without "@") [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits): (for example) [v2]: Fixup CPU_* usage that caused gcc malloc error. | [12:41] |
| anyway, I'm ok on accepting just '[hverkuil: foo]', as it seems that at least half of the patches have this new pattern
I may end sending a patch changing this at submitting-patches.pl. though... sailus: you said that you would be replying with some oxymoron cases at the glossary patch series, but I'm missing such e-mail | [12:51] | |
| ................................................................................................... (idle for 8h13mn) | ||
| sailus | mchehab: Yes, I know.
-ENOTIME I'll try to do that by Monday. | [21:08] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |