Messages in this thread | | | From | Ard Biesheuvel <> | Date | Thu, 23 Apr 2020 20:47:00 +0200 | Subject | Re: [PATCH crypto-stable v3 1/2] crypto: arch/lib - limit simd usage to 4k chunks |
| |
On Thu, 23 Apr 2020 at 20:42, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Apr 23, 2020 at 09:18:15AM +0200, Ard Biesheuvel wrote: > > FYI: you shouldn't cc stable@vger.kernel.org directly on your patches, > > or add the cc: line. Only patches that are already in Linus' tree > > should be sent there. > > Not true at all, please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly. Please do not spread incorrect > information. > > And Jason did this properly, he put cc: stable@ in the s-o-b area and > all is good, I will pick up this patch once it hits Linus's tree. > > And there is no problem actually sending the patch to stable@vger while > under development like this, as it gives me a heads-up that something is > coming, and is trivial to filter out. > > If you really want to be nice, you can just do: > cc: stable@kernel.org > which goes to /dev/null on kernel.org, so no email will be sent to any > list, but my scripts still pick it up. But no real need to do that, > it's fine. >
OK, thanks for clearing this up.
So does this mean you have stopped sending out 'formletter' auto-replies for patches that were sent out to stable@vger.kernel.org directly, telling people not to do that?
> > Also, the fixes tags are really quite sufficient. > > No it is not, I have had to dig out patches more and more because people > do NOT put the cc: stable and only put Fixes:, which is not a good thing > as I then have to "guess" what the maintainer/developer ment. > > Be explicit if you know it, cc: stable please. >
OK
> > In fact, it is > > actually rather difficult these days to prevent something from being > > taken into -stable if the bots notice that it applies cleanly. > > Those "bots" are still driven by a lot of human work, please make it > easy on us whenever possible. >
Sure.
| |