Hi Kees, On Wed, Sep 30, 2020 at 11:02:32AM +0200, Solar Designer wrote: > Messages that are auto-approved don't create any work for either of us, > and that's the majority of them. Messages that are held for moderation > (until I add the sender to moderation bypass) do involve some work, but > that's the only way to avoid spam on the list. I think that amount of > work is small compared to all subscribers' time wasted on occasional > spam on the list. If it's unacceptable for you, I can remove you from > list moderators and maybe add someone else as a co-moderator. I think > it wouldn't be hard for us to find a volunteer. Please let me know. Someone has already volunteered. I'd also like to hear from someone possibly not as over-qualified and as busy as that person is. ;-) Kees, if you'd like to step down as a co-moderator for kernel-hardening, please let me know. We'll add someone else (so that this doesn't depend solely on me being around). To avoid misinterpretation: I am not suggesting that you need to step down, totally not. I merely feel that you need to have the option since you expressed unhappiness with having to spend effort on that. > That's a major misunderstanding. I cared primarily about the well-being > of KSPP, and not so much about hosting/administering a list with a > policy I disagree with in a minor way, which I accepted. I didn't want > to continue that discussion "for very long" as it "hurts actual work", > not because I disagreed with you (although I did) and insisted on that > deciding list policy (I did not, and it did not). BTW, now we're having > another such discussion that hurts actual work, so I am also not going > to continue it for very long. It is weird that I now feel I have to spell it out explicitly, but I do, so: Kees, please don't use my saying that I don't want to continue this bikeshed discussion "for very long" as an excuse for lack of coordination on your part, again. That's not a valid excuse, nor do you need one. You can always coordinate with me off-list if you prefer, but I don't mind this thread continuing on the list for a little while. > 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 paragraph above, so at least you need to confirm whether my guesses are correct, or correct me if they are not. 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". I think topics more desirable on kernel-hardening would be deciding on such replacements in general (not patches for individual instances), introduction of such helpers, etc. Also summaries of work done (e.g., "this-many instances of that-thing were updated to new conventions in the kernel over the last month as discussed in those threads seen in that list archive"). I use examples from the past because that's what we have, but I use them to illustrate roughly what kinds of things we could possibly have on one list vs. the other in the future. Thanks, Alexander
