Hi Greg, Hi Pratyush, On Wed, Apr 05, 2023 at 04:22:58PM +0200, Greg KH wrote: > On Wed, Apr 05, 2023 at 03:33:20PM +0200, Pratyush Yadav wrote: > > On Wed, Apr 05 2023, Greg KH wrote: > > > > > On Wed, Apr 05, 2023 at 02:26:04PM +0200, Greg KH wrote: > > >> On Wed, Apr 05, 2023 at 01:47:52PM +0200, Pratyush Yadav wrote: > > >> > On Wed, Apr 05 2023, kernel test robot wrote: > > >> > > > >> > > Hi, > > >> > > > > >> > > Thanks for your patch. > > >> > > > > >> > > FYI: kernel test robot notices the stable kernel rule is not satisfied. > > >> > > > > >> > > Rule: 'Cc: stable@xxxxxxxxxxxxxxx' or 'commit <sha1> upstream.' Sorry the info at here is not accurate enough. We will improve the wording. > > >> > > > >> > I think the robot should also learn to look at the 'To:' header :-) > > >> > > >> Nope, the robot is correct, you submitted this incorrectly. > > > > > > Wait, maybe, I can't tell. > > > > My point is that it does not matter much if stable@xxxxxxxxxxxxxxx is in > > Cc or To. It gets the email regardless. In fact, that seems quite a > > common practice to me [0][1]. So I'd say it would be nice if the robot > > did not needlessly complain about this. > > > > [0] https://lore.kernel.org/stable/20230403140414.236685532@xxxxxxxxxxxxxxxxxxx/ > > [1] https://lore.kernel.org/stable/20230403140415.140110769@xxxxxxxxxxxxxxxxxxx/ > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=87f93d82e0952da18af4d978e7d887b4c5326c0b This warning is not caused by "stable@xxxxxxxxxxxxxxx is in To or Cc". The document at [3] gives three options for sending patches to stable, and seems option 3 should apply on this patch: [3] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html Option 3 Send the patch, after verifying that it follows the above rules, to stable@xxxxxxxxxxxxxxx. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish it to be applied to. The examples in link [0][1] have "upstream commit" in the changelog, but this patch doesn't, so the robot flags a warning. > The robot replaces my bot (well, aguments this), and it rightfully flags > many patches that are sent to stable that are not done so correctly, so > that the submitter can then fix them up. The number of "false > positives" like this is pretty low, as hey, even I got it wrong when > reading this "by hand". Thanks for the affirmation of our robot. Could you help give some suggestions so we can further improve the robot to reduce "false positives"? Do we still need to check "upstream commit" in changelog for similar cases? -- Best Regards, Yujie
