On Mon, Oct 05, 2020 at 04:14:56PM +0200, Solar Designer wrote: > > So your suggested use of kernel-hardening@ is for discussions of Linux > > kernel hardening projects or work-in-progress that isn't to be submitted > > upstream or isn't yet submitted upstream. If, and as soon as, a patch > > series is sent upstream, that should go on the new linux-hardening@ > > list? And only in there or also CC'ed to kernel-hardening@? I'm just > > trying to understand. > > We need you to comment on the above. I hope you did have some idea of > how the topics would be split between the two lists, but you haven't > really specified that yet. I tried to make guesses in the paragrapht > above, so at least you need to confirm whether my guesses are correct, > or correct me if they are not. Perhaps this would be a helpful way of framing the issue. The list specified in the MAINTAINERS list is the one that is going to be automatically returned by the scripts/get_maintainer_pl script. This gets used by kernel newbies who send things like white space fixes and spelling corrections to said developer's list. For most vger.kernel.org lists, we mix high-level architectural discussions with things like trivial patches. It sounds like you don't want these sorts of administrivia messages sent to the openwall list. Is that correct? If that is true, it's not something that moderation will fix by somewhere, but it that traffic needs to go *somewhere*. > I see there are already a few threads on linux-hardening, and those are > not CC'ed to kernel-hardening. I am pleasantly surprised that those > threads are about rather minor changes, which while acceptable to have > on kernel-hardening as well IMO do not add much value to discussions > desirable on kernel-hardening: "Replace one-element array with > flexible-array member", "Use flex_array_size() helper", "Use > array_size() helper", "Replace one-element array and save heap space", > "Use fallthrough pseudo-keyword". Exactly, that's the sort of thing that needs its own mailing list, and moderation won't fix. The challenge is whether we can get people to subscribe to two lists, and redirect messages to the right list when the topic changes. Sometimes what starts off as a seemingly trivial patch fix turns intot an arhitectural discussion. Expecting people to change the mailing list name when the scope of the discussion changes is probably not realistic --- not to mention that when such a change *does* happen, there may be missing context that will be lost since the original message started out on "administrivia" list. (Which is why we generally don't separate out those two buckets on the standard kernel subsystem lists on vger.) Cheers, - Ted
