On Wed, Apr 12 2023, Yujie Liu wrote: > 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. It is entirely possible for a patch for a stable tree to not have an upstream commit. For example, I sent a patch recently [0] that was caused by a buggy backport. The patch to fix it of course would not have an upstream commit since upstream was correct from the get-go. The bot should not complain about such patches. Funnily enough the bot did not complain there even though that patch also does not have an upstream commit hash. But it puts stable@xxxxxxxxxxxxxxx in Cc instead of To. [0] https://lore.kernel.org/all/20230411130210.113555-1-ptyadav@xxxxxxxxx/ > >> 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 -- Regards, Pratyush Yadav Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
