All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>, corbet@lwn.net
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] Documentation/process: kernel maintainer PGP guide
Date: Wed, 31 Jan 2018 09:18:11 +0200	[thread overview]
Message-ID: <87bmhajy30.fsf@intel.com> (raw)
In-Reply-To: <20180130184917.GA32095@gmail.com>

On Tue, 30 Jan 2018, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> This guide is an adapted version of the more general "Protecting Code
> Integrity" guide written and maintained by The Linux Foundation IT for
> use with open-source projects. It provides the oft-lacking guidance on
> the following topics:
>
> - how to properly protect one's PGP keys to minimize the risks of them
>   being stolen and used maliciously to impersonate a kernel developer
> - how to configure Git to properly use GnuPG
> - when and how to use PGP with Git
> - how to verify fellow Linux Kernel developer identities
>
> I believe this document should live with the rest of the documentation
> describing proper processes one should follow when participating in
> kernel development. Placing it in a wiki on some place like kernel.org
> would be insufficient for a number of reasons -- primarily, because only
> a relatively small subset of maintainers have accounts on kernel.org,
> but also because even those who do rarely remember that such wiki
> exists. Keeping it with the rest of in-kernel docs should hopefully give
> it more visibility, but also help keep it up-to-date as tools and
> processes evolve.

FWIW, agreed on having this with the kernel documentation.

I can't say I reviewed it, but glancing through I didn't spot any errors
either. Lots of good stuff.

Just one nit, I think it would be better to move the Maintainer: bit
from the end near the top as a reStructuredText field list. See 'git
grep :Author:' under Documentation for examples. Could even add a
MAINTAINERS entry to improve your chances of being Cc'd on changes.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

  reply	other threads:[~2018-01-31  7:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30 18:49 [PATCH] Documentation/process: kernel maintainer PGP guide Konstantin Ryabitsev
2018-01-31  7:18 ` Jani Nikula [this message]
2018-02-01 14:45   ` Konstantin Ryabitsev
2018-02-01 14:42 ` [PATCH v2] " Konstantin Ryabitsev
2018-02-01 18:14   ` Jonathan Corbet
2018-02-01 20:50     ` Konstantin Ryabitsev
2018-02-05 11:22   ` Luc Van Oostenryck

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=87bmhajy30.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.