All of lore.kernel.org
 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, 06 Mar 2020 22:40:26 +0000	[thread overview]
Message-ID: <20200306224026.GA4095@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2003062148050.2990@felia>

On Fri, Mar 06, 2020 at 09:50:44PM +0100, Lukas Bulwahn wrote:
> 
> 
> On Fri, 6 Mar 2020, Jarkko Sakkinen wrote:
> 
> > 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.
> > 
> 
> Got it. I did not intend to emphasize any urgency; I will not continue 
> to do that for patches of this clean-up type.

Anyway, thank you and I've applied your patch and will include it to my
v5.7 PR.

/Jarkko

WARNING: multiple messages have this Message-ID (diff)
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: Sat, 7 Mar 2020 00:40:26 +0200	[thread overview]
Message-ID: <20200306224026.GA4095@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2003062148050.2990@felia>

On Fri, Mar 06, 2020 at 09:50:44PM +0100, Lukas Bulwahn wrote:
> 
> 
> On Fri, 6 Mar 2020, Jarkko Sakkinen wrote:
> 
> > 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.
> > 
> 
> Got it. I did not intend to emphasize any urgency; I will not continue 
> to do that for patches of this clean-up type.

Anyway, thank you and I've applied your patch and will include it to my
v5.7 PR.

/Jarkko

  reply	other threads:[~2020-03-06 22:40 UTC|newest]

Thread overview: 10+ 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-05 20:30 ` Lukas Bulwahn
2020-03-06  5:03 ` Sumit Garg
2020-03-06  5:15   ` Sumit Garg
2020-03-06 19:31 ` Jarkko Sakkinen
2020-03-06 19:31   ` Jarkko Sakkinen
2020-03-06 20:50   ` Lukas Bulwahn
2020-03-06 20:50     ` Lukas Bulwahn
2020-03-06 22:40     ` Jarkko Sakkinen [this message]
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=20200306224026.GA4095@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 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.