From: Linus Walleij <linus.walleij@linaro.org>
To: linux-doc@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Cc: Kees Cook <keescook@chromium.org>,
Dan Williams <dan.j.williams@intel.com>,
Jakub Kicinski <kuba@kernel.org>,
Christian Brauner <brauner@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: Documentation/process: Add Linux Kernel Contribution Maturity Model
Date: Thu, 15 Dec 2022 16:14:36 +0100 [thread overview]
Message-ID: <20221215151436.236233-1-linus.walleij@linaro.org> (raw)
In-Reply-To: <20221214185714.868374-1-tytso@mit.edu>
> The goal is to encourage, in a management-friendly way, companies to
> allow their engineers to contribute with the upstream Linux Kernel
> development community, so we can grow the "talent pipeline" for
> contributors to become respected leaders, and eventually kernel
> maintainers.
These are noble goals. Also the bullet list is short, formal, and
to the point. This is nice.
I kind of side with Michael Tsirkin's point that quantitative
measures of performance can be harmful or give a false impression
of control. Consider this example:
linux$ git log --oneline --author=Walleij |wc -l
4301
linux$ git log --oneline --author=McKenney |wc -l
3346
There is something about some code in the kernel being more
"core" than others that needs to be taken into account, albeit
it is maybe an elusive concept. There is a hierarchy from
contributing syntactic changes to coding style to contributing
and maintaining say RCU.
That can be judged by peers and is addressed in other points in
the document so what about just dropping this paragraph?
Then there is this:
> +* Software Engineers are encouraged to spend a portion of their work
> + time focused on Upstream Work, which is defined as reviewing patches
> + or papers,
Papers! If we are linking ourselves to the Scientific Community
(and I see that as a good thing) we should certainly drop a few
words about it. It's a place of (ideally) meritocracy and
formal review of contributions.
Here is a real nice paper:
https://kernel.dk/systor13-final18.pdf
as a community we should probably produce more like this.
Or maybe you meant to say "mails". I don't know.
On a side note I would say that this document creates a really
serious cognitive dissonance with the document
Documentation/process/management-style.rst
so just for the fun of it I think this document should reference
that latter document as a guideline for how Software Engineers
will be evaluated in the community when they take on . It is a
nice nod to the nature of conflicting interests and worldviews
we need to deal with.
Yours,
Linus Walleij
next prev parent reply other threads:[~2022-12-15 15:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 18:57 [PATCH] Documentation/process: Add Linux Kernel Contribution Maturity Model Theodore Ts'o
2022-12-15 9:53 ` Michael S. Tsirkin
2022-12-15 15:14 ` Linus Walleij [this message]
2022-12-16 8:23 ` Bagas Sanjaya
2022-12-16 8:14 ` [PATCH] " Bagas Sanjaya
2022-12-16 14:34 ` Theodore Ts'o
2022-12-27 19:12 ` Florian Fainelli
2023-02-08 20:31 ` Jonathan Corbet
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=20221215151436.236233-1-linus.walleij@linaro.org \
--to=linus.walleij@linaro.org \
--cc=brauner@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=tytso@mit.edu \
/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 NNTP newsgroup(s).