On Wed, Dec 9, 2020 at 2:31 AM Dan Carpenter <dan.carpen...@oracle.com> wrote: > > On Wed, Dec 09, 2020 at 12:54:30AM -0800, Joe Perches wrote: > > On Wed, 2020-12-09 at 10:58 +0300, Dan Carpenter wrote: > > > On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote: > > > > On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote: > > > > > > > > > If not "Adjusted-by", what about "Tweaked-by", "Helped-by", > > > > > "Corrected-by"? > > > > > > > > Improved-by: / Enhanced-by: / Revisions-by: > > > > > > > > > > I don't think we should give any credit for improvements or enhancements, > > > only for fixes. > > > > Hey Dan. > > > > I do. If a patch isn't comprehensive and a reviewer notices some > > missing coverage or algorithmic performance enhancement, I think that > > should be noted. > > > > > Complaining about style is its own reward. > > > > <chuckle, maybe so. I view it more like coaching...> > > > > I believe I've said multiple times that style changes shouldn't require > > additional commentary added to a patch. > > > > I'm not making any suggestion to comment for style, only logic or defect > > reduction/improvements as described above. > > How about we make the standard, "Would this fix be backported to stable?" > > > > > > Having to redo a patch is already a huge headache. Normally, I already > > > considered the reviewer's prefered style and decided I didn't like it. > > > > Example please. We both seem to prefer consistent style. > > > > For example, if you have a signedness bugs: > > ret = frob(unsigned_long_size); > - if (ret < unsigned_long_size) > + if (ret < 0 || ret < unsigned_long_size) > vs: > + if (ret < (int)unsigned_long_size) > goto whatever; > > To me, whoever fixes the bug gets to choose their prefered style but > maybe some reviewers have strong feelings one way or the other. > > > > Then to make me redo the patch in an ugly style and say thank you on > > > top of that??? Forget about it. > > > > Not a thing I've asked for. > > > > > Plus, as a reviewer I hate reviewing patches over and over. > > > > interdiff could be improved. > > > > > I've argued for years that we should have a Fixes-from: tag. The zero > > > day bot is already encouraging people to add Reported-by tags for this > > > and a lot of people do. > > > > It's still a question of what fixes means in any context. > > > > https://www.google.com/search?q=%27fixes-from%3A%27%20carpenter%20site%3Alore.kernel.org > > gives: > > It looks like there aren't many great matches for your search > > > > No, I mean people add Reported-by tags for fixes to the original commit > like in commit f026d8ca2904 ("igc: add support to eeprom, registers and > link self-tests").
For after the fact post-processing of tags to generate summary reports, is there a significant difference between Reported-by for "original commit motivation" and Reported-by for "follow-on fixups"? Especially since this practice of Reported-by for fixups is already deployed in the tree (at least kbuild-robot credit reports and my subsystems operate this way). If the fix is a slightly late and needs to come as a follow-on patch the tag will be Reported-by on that fix. I fail to perceive a benefit in augmenting the tag to indicate the resolution of the race condition of the commit making it upstream.