From: Andy Lutomirski <luto@kernel.org>
To: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
Tech-board-discuss@lists.linux-foundation.org
Subject: [Tech-board-discuss] TAB nomination
Date: Mon, 12 Nov 2018 22:12:32 -0800 [thread overview]
Message-ID: <CALCETrX3wM2QdaweXT3JGKU8NTGrgRmxQoh28uqyWkSCfJLcfQ@mail.gmail.com> (raw)
[resend -- I tried to send this earlier, but it seems to have
disappeared into the ether]
I'd like to nominate myself for the TAB.
I wrote my first kernel patch in 2005 or so when I fixed an obscure
kernel bug, and I've been contributing to the kernel more seriously
for about nine years. In that time, I've been mentored (or perhaps
groomed) by quite a few kernel developers, I've had my patches
objected to plenty of times (politely and sometimes less politely),
I've cleaned up a lot of x86 code and a decent amount of generic code,
and I've reveiwed a whole lot of other people's code. In the latter
endeavor, I've tried to pass the mentoring mentality on -- I do my
best to treat problematic patches as an opportunity to help their
authors improve the patches and their own knowledge of the kernel.
I've been a member of the security@kernel.org list for several years,
and, for better or for worse, I was heavily involved in the very early
Meltdown mes^Wcoordination effort as well as some other less well
publicized cross-vendor efforts. While I believe that the
security@kernel.org process works quite well for smaller, Linux-only
security issues, for issues where the reporter reasonably expects
serious cross-vendor coordination (like Meltdown, Spectre, L1TF, etc),
I think that some measures could be taken by the Linux Foundation to
help prepare for a more efficient and less politicized process. I've
discussed some of these on previous ksummit-discuss threads, and I
think that the TAB would be an appropriate venue to explore some of
these ideas.
Finally, an obligatory comment about the Code of Conduct. I was not
meaningfully involved in most of the CoC process. I think we ended up
with a reasonable CoC interpretation document, but I find it
unfortunate that the kernel now has both the somewhat ill-fitting CoC
itself as well as the interpretation document. For contributors who
are merely trying to follow the rules, it's harder than it ought to be
to tell what the rules are. More importantly, I think there's more
focus on rules than the whole situation really deserved. When I
started working on low-level x86 code, I was welcomed quite well by
the maintainers, but that had nothing to do with their following any
particular rules, and certainly not because there were rules with
teeth. My welcome was good because the maintainers were welcoming --
they treated my mistakes as learning opportunities and did not insult
me or reject my contributions out of hand. This idea doesn't just
apply to new contributors -- I regularly review patches from
longstanding kernel programmers who are touching a subsystem that
they're not familiar with, and I regularly submit patches to parts of
the kernel that I haven't been heavily involved with. I try to be
friendly and helpful when reviewing these types of contribution, and I
hope for the same treatment in my own contributions. I would like to
see more focus on this idea. If someone reviews a patch or criticizes
a developer in a way that's less than ideal, I would rather see other
community members help them see *how* their email was problematic and
how they could have done better. In my view, this would be much
better than merely having a process to determine whether the offending
email violated a code, let alone whether it was worthy of some sort of
sanction.
Thank you all for your consideration,
Andrew Lutomirski
P.S. I won't be at LPC this year. I hope to make it next year, though.
next reply other threads:[~2018-11-13 6:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 6:12 Andy Lutomirski [this message]
2018-11-13 6:58 ` [Tech-board-discuss] [Ksummit-discuss] TAB nomination Steven Rostedt
2018-11-13 7:09 ` Andy Lutomirski
2018-11-13 19:06 ` Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2019-09-05 19:03 [Tech-board-discuss] " Jonathan Corbet
2018-11-12 20:09 Laurent Pinchart
2018-11-12 20:36 ` Steven Rostedt
2018-11-12 19:23 [Tech-board-discuss] TAB Nomination Pavel Machek
2018-11-12 20:26 ` Steven Rostedt
2018-11-10 20:52 Dan Williams
2018-11-10 18:44 Laura Abbott
2018-11-08 5:14 [Tech-board-discuss] TAB nomination Kees Cook
2018-11-08 14:42 ` Steven Rostedt
[not found] <340499F8-3113-4C8E-946B-3C33A1C4E3A7@fb.com>
2018-11-06 23:42 ` Olof Johansson
2016-10-26 16:02 [Tech-board-discuss] TAB Nomination Josh Triplett
2016-10-26 17:57 ` Greg KH
2016-10-26 18:06 ` Steven Rostedt
2016-10-26 18:26 ` Josh Triplett
2009-10-13 1:45 [Tech-board-discuss] TAB nomination Roland Dreier
2009-10-13 15:03 ` James Bottomley
2008-09-12 17:04 Chris Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrX3wM2QdaweXT3JGKU8NTGrgRmxQoh28uqyWkSCfJLcfQ@mail.gmail.com \
--to=luto@kernel.org \
--cc=Tech-board-discuss@lists.linux-foundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).