linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Sumit Garg <sumit.garg@linaro.org>,
	James Bottomley <jejb@linux.ibm.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	Sebastian Duda <sebastian.duda@fau.de>,
	Joe Perches <joe@perches.com>,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] MAINTAINERS: adjust to trusted keys subsystem creation
Date: Fri, 6 Mar 2020 21:31:27 +0200	[thread overview]
Message-ID: <20200306193127.GJ7472@linux.intel.com> (raw)
In-Reply-To: <20200305203013.6189-1-lukas.bulwahn@gmail.com>

On Thu, Mar 05, 2020 at 09:30:13PM +0100, Lukas Bulwahn wrote:
> Commit 47f9c2796891 ("KEYS: trusted: Create trusted keys subsystem")
> renamed trusted.h to trusted_tpm.h in include/keys/, and moved trusted.c
> to trusted-keys/trusted_tpm1.c in security/keys/.
> 
> Since then, ./scripts/get_maintainer.pl --self-test complains:
> 
>   warning: no file matches F: security/keys/trusted.c
>   warning: no file matches F: include/keys/trusted.h
> 
> Rectify the KEYS-TRUSTED entry in MAINTAINERS now and ensure that all
> files in security/keys/trusted-keys/ are identified as part of
> KEYS-TRUSTED.
> 
> Co-developed-by: Sebastian Duda <sebastian.duda@fau.de>
> Signed-off-by: Sebastian Duda <sebastian.duda@fau.de>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---

Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

> Changes to v1:
>   - use a global pattern for matching the whole security/keys/trusted-keys/
>     directory.
> Changes to v2:
>   - name the correct directory in the commit message
> 
> Sumit, please ack.
> Jarkko, please pick this patch v3.

Please tell me why you emphasize the moment when a patch that does not
fix a critical bug is picked?

Do you have systems that break because the MAINTAINERS file is not
updated?

It will end up in v5.7 PR for sure but saying things like that is same
as saying that there would be some catastrophically urgent need to still
squeeze the patch into v5.6. Unless you actually have something critical
in your hand, please stop doing that.

/Jarkko

  parent reply	other threads:[~2020-03-06 19:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 20:30 [PATCH v3] MAINTAINERS: adjust to trusted keys subsystem creation Lukas Bulwahn
2020-03-06  5:03 ` Sumit Garg
2020-03-06 19:31 ` Jarkko Sakkinen [this message]
2020-03-06 20:50   ` Lukas Bulwahn
2020-03-06 22:40     ` Jarkko Sakkinen

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=20200306193127.GJ7472@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=jejb@linux.ibm.com \
    --cc=joe@perches.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=sebastian.duda@fau.de \
    --cc=sumit.garg@linaro.org \
    --cc=zohar@linux.ibm.com \
    /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).