Em Tue, 23 Apr 2024 00:04:01 +0200 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> escreveu: > On Mon, Apr 22, 2024 at 10:46:37PM +0100, Mauro Carvalho Chehab wrote: > > Em Mon, 22 Apr 2024 15:25:18 -0400 > > Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> escreveu: > > > > > On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote: > > > > @Greg, BTW: should this be stable+noautosel@xxxxxxxxxx or have a > > > > 'vger.' > > > > > > No vger, just stable+whatever@xxxxxxxxxx. > > > > > > > in it, e.g. stable+noautosel@xxxxxxxxxxxxxxx? I assume without 'vger.' > > > > is fine, just wanted to be sure, as > > > > Documentation/process/stable-kernel-rules.rst in all other cases > > > > specifies stable@xxxxxxxxxxxxxxx, so people are likely to get confused. > > > > :-/ #sigh > > > > > > These serve two different purposes: > > > > > > stable@xxxxxxxxxx (goes into devnull) > > > stable@xxxxxxxxxxxxxxx (actual mailing list) > > > > > > Confusion happens all the time, unfortunately. > > > > Yeah, I did already used stable@xxxxxxxxxx a few times in the > > past. > > > > IMO, the best would be either for stable to also accept it or for > > kernel.org mail server to return an error message (only to the > > submitter) warning about the invalid address, eventually with a > > hint message pointing to the correct value. > > stable@xxxxxxxxxx is there to route to /dev/null on purpose so that > developers/maintainers who only want their patches to get picked up when > they hit Linus's tree, will have happen and not notify anyone else. > This is especially good when dealing with security-related things as we > have had MANY people accidentally leak patches way too early by having > cc: stable@xxxxxxxxxxxxxxx in their signed-off-by areas, and forgetting > to tell git send-email to suppress cc: when sending them out for > internal review. Nice! didn't know about that. On a quick check, the only place at documentation mentioning it without vger is at checkpatch.rst. Perhaps it would make sense to document that as well. > Having that bounce would just be noisy for the developers involved. > > thanks, > > greg k-h
