From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C85628469F; Sun, 19 Apr 2026 22:08:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776636529; cv=none; b=EsnhbhO4KwrSYryW4ZD2yH7z0rF7oHM3NCXICUhPa4wQubbP1SV3gDP/EbiCbe/CINAzGODTjKmOksVsXOtWfMWz40RvCFODzVxlqtIV/524OwbAFSssn41UTCYXpIBwtzD9l+YAm4epo3XsBslq+tSQvQOXF55rqJtq4nM0AC8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776636529; c=relaxed/simple; bh=wStAdO7mfEx4FH3qgv15bmA6U5wIK3h8L2nlKjb+EM0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Spya0fitNIpFJrKBSiAU2PvnVz4QRIiJy4anm8VZGKtUWtdtj8/aMXKKwNiXM4Bsy09kw1ubeH93e5M+w9f/eIuBzm7+aWEgFA6XSyt7xIELwX4zp4JYT3SBJK5EQdjP5Wcjz2/ouHV4fuQQr2FRfse7NZr6cZNFAG6hcDD6lYA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BP8Abvn9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BP8Abvn9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6CDBC2BCAF; Sun, 19 Apr 2026 22:08:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776636529; bh=wStAdO7mfEx4FH3qgv15bmA6U5wIK3h8L2nlKjb+EM0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BP8Abvn9pgBsjSRLy4QOGLHYh5r5/tpadgJ05Gl9WjucdQ/zGUXFUl6VU8l5IxXzs 5FSXjPazwWAg3+mAFWaj33FPsIWwGuEJQDnYcM2NnPiHKxHuDMQje/vwAC7BLotqMU HDgbMvyyiPE9AKb6E3YtZydrE9ReK0TZOVAzQz/HVf9U9A1nIW2/aGf0rw9CiGkK5V gY40cHLW+BowmbxHVxygThCFfWev3vgIh57pGMl+atZ9f7IwQlmhcoOSbsdMG8I2I7 wrECDl+4c1Al4B5h1xt+Tlu4jczXlpjApraspiLsQpQkbx4bFYHSZRCD+UIXh7Ius7 ZHtlzaDU+xsuw== Date: Mon, 20 Apr 2026 01:08:45 +0300 From: Jarkko Sakkinen To: Linus Torvalds Cc: David Howells , Herbert Xu , "David S. Miller" , keyrings@vger.kernel.org, linux-integrity@vger.kernel.org Subject: Re: [GIT PULL] KEYS: keys-next-7.1-rc1 Message-ID: References: Precedence: bulk X-Mailing-List: linux-integrity@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Apr 19, 2026 at 02:52:06PM -0700, Linus Torvalds wrote: > On Sun, 19 Apr 2026 at 14:38, Jarkko Sakkinen wrote: > > > > I tested both PRs for the same baseline with two separate buildroot builds of > > You threw away any and all testing that had been done by anybody else > in linux-next. > > And you rebased things on top of a random commit-of-the-day during the > merge window, when things are possibly unstable due to all the *other* > churn going on. > > In other words, you did *EVERYTHING* that you shouldn't be doing, and > that the documentation tells you not to do. > > The WHOLE POINT of being in linux-next and being ready when the merge > window opens is gone. All for apparently nothing. > > Those stable cc tags do not add *any* value, since you could just have > cc'd stable later instead. > > I'm not pulling this. You need to stop doing this pointless churn, and > read the docs on rebasing. See > > Documentation/maintainer/rebasing-and-merging.rst > > about how you are *not* supposed to randomly just rebase, and > _particularly_ not rebase on top of some random state during the merge > window. "A frequent cause of merge-window trouble is when Linus is presented with a patch series that has clearly been reparented, often to a random commit, shortly before the pull request was sent. The chances of such a series having been adequately tested are relatively low - as are the chances of the pull request being acted upon." OK, point digested. I can update 'next' to contain only fixes from these PRs, and hold on up til doing PR for -rc2 (as corrective step). > > Linus BR, Jarkko