From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 5A8792E8DE3 for ; Tue, 26 May 2026 08:33:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779784395; cv=none; b=klRSauucCsg3fFd/6aePfN6XlORjYBvIT0Y7mhW7TcubIHVFaqByzA3L7ToDJKo48iXgpo8zXXOgZt1cBalJGvyr7990Gh4NjHbLxWObSQjOaYuJcoi0RPkkCGMtuhhru5XRABrTrcaAkiBsi2cyQpUd9FLCQZeezsnjpSrqHt8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779784395; c=relaxed/simple; bh=ZWy7Rcx3R6qFnZjyKosdkRehi5dLXhtgyFC+BQ3px5s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JbSx9ewDA2FWTOZuF2J3V5fj8aGNzZBBa/RS3XGZvVFN0U6Z8dV+YCBR7MAHMMmwZOacEbDNiaiJqCNszwpkuOInKXJ3AIIXC9fml//s3Jmdb65BAzEyzt59xL7N4iRKu+/ePW8QHbblwoM57XXwn0UvNUgdfyEDaxy/rBFWe7I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MvCNSSAj; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MvCNSSAj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FA341F000E9; Tue, 26 May 2026 08:33:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779784394; bh=ZWy7Rcx3R6qFnZjyKosdkRehi5dLXhtgyFC+BQ3px5s=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=MvCNSSAjNnejUmuowmyUxMavGD2jehxjtu8HsCUYPWbPYQQ0jGYC6w3Fe0q6QmtIn hx82APj7LuOp8MQndXODZIoWX++RnqsZwSelVaiOJAUkeyw+yVMxPe2c5vwnWucCHS S2+FjRy5fPOeAiw2mlr91ibRcQBcdFtZyyVtrW1xmbxYiT3VdRcIRoOw26PdNPlpD7 17PoI2AGkQs5tOFNBpTpTa4shuQNX/dv0dx9zYypquxBMV32lYEw+wTinRyDjDciXo Ohj/LuACLqvF1M7Tu8pabf4u1KwmfTeFrsM6NaudxSyHbMSquNmCQ8dgzofT89I6xF k7oSumqIy3LXg== Date: Tue, 26 May 2026 09:33:08 +0100 From: Lorenzo Stoakes To: "David Hildenbrand (Arm)" Cc: Nico Pache , "Vlastimil Babka (SUSE)" , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, liam@infradead.org, mhocko@suse.com, rppt@kernel.org, vbabka@suse.cz, willy@infradead.org Subject: Process (was Re: [PATCH mm-hotfixes-unstable v18 00/14] khugepaged: add mTHP) collapse support Message-ID: References: <20260522150009.121603-1-npache@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: [trimmed cc list to avoid noise, apologies if I excluded anybody who is interested in this!] On Fri, May 22, 2026 at 11:13:42PM +0200, David Hildenbrand (Arm) wrote: > On 5/22/26 18:11, Nico Pache wrote: > > On Fri, May 22, 2026 at 9:13 AM Vlastimil Babka (SUSE) > > wrote: > >> > >> On 5/22/26 17:07, Nico Pache wrote: > >>> > >>> Whoops I manually changed the coverletter subject to reflect that this > >>> in on mm-hotfixes-unstable but never updated the others... > >> > >> But why? That branch is for hotfixes that would go to the current 7.1-rcX > >> series. mm-unstable would be the correct one for this, AFAICT. > > > > Sorry this was a misunderstanding. The goal here was to base this off > > the closest base commit behind where my v17 already lies in the tree. > > Ah, I guess this is a problem of "v17 is already in mm-unstable, so against what > to base v18". > > Yeah, we touched on that problem in the LSF/MM process discussion ... I may be misremembering but... :) [correct me if wrong]: Wasn't the general conclusion that we maintain a stable branch (Linus's tree + stuff that's been reviewed and is locked in for next release), and have people base work against that? This would be 'source of truth' and what we eventually send to Linus. In that world, the maintainers perform conflict resolution, but with git rerere we need only do this once. We'd have mm-new which would contain everything for testing. SO my question is - would we even need an mm-unstable in that world? What role would it perform? Surely we'd want the stable branch going to linux-next, so it's not that, it's not quite initial testing either as mm-new would perform that duty. It would potentially make life a bit easier for somebody doing a new series to avoid merge conflicts, but that could then make life harder because there'd be an implicit dependency of their series on what's-in-mm-unstable? If everything's based on the stable branch, things are surely clearer? Curious what people think here. (I also wonder if we could have branches for versions of series so we could do some kind of an easy diff between versions but maybe that'd create too much noise :) > > -- > Cheers, > > David Thanks, Lorenzo