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 D356A28CF6F for ; Mon, 1 Jun 2026 16:16:05 +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=1780330566; cv=none; b=g34veolbPsDFXfaVSF/zuEQSpl2nRCWxSjt5RQS6mmO2I8wEgm4FfyJ6OYpH7rb67J+mT7aC5iGYH6uzChRZERQtFEUkhcJcBmfWV+9NJD96/cAzIbf/piwOFYDTb1HD5dpcGZuIs5OR4VRm32rs6Xj0NB/lFMX2OoB8AVX5BHc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780330566; c=relaxed/simple; bh=klLNQk57exDbXR49S/i0hMmexp2/+GhTI8W+FFTNTQk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=P5MQyWQ58PJqITLY49ir1d72Z8k29EZJD/tW5AsmfGDHCUjMM/1XFEA4uAs9WngRjSqJjwAnFffMB+bDJxFOTx5LdlnpwpQucq0fXx/NtdjCzQS+E/5tYDmpy99HlgNxuO2VqH58KXotNP4yrZb6c/1MJ7VXK3C3HMT3ywMRMmE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jtIF99yu; 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="jtIF99yu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2DF91F00893; Mon, 1 Jun 2026 16:16:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780330565; bh=klLNQk57exDbXR49S/i0hMmexp2/+GhTI8W+FFTNTQk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jtIF99yuAJp2t3Jul9D91kdBj5BR1YsqbTfn9826AwKdxeMfpoqRpg/+j058mg8h2 0ql9Ou18UJ9ZNGtptikM6OFNRBJipEAf3YW1cYtoaE0kQ00JxsEJmXjYaR2bXBzwPL LkIBmeNjMpv99bMO6xzfpVr8CyNQmmSEM+OwF6mkXMWSAyNgzMqOKLuDMw5uP4FUSk ocuWTc8eXOfe4r20egDLOwPRya0KLCXUaYBCJ5x+iDmbgXa4TZuXUPVdMoSoLow0xM vS/GbpOI0jTXZcI8QYAfaYRayEUWt0RkjVTSISgNJruqBuLp2k5yxAXN91/Ac634SL q17mwRRyX2vbA== Date: Mon, 1 Jun 2026 17:16:00 +0100 From: Lorenzo Stoakes To: "David Hildenbrand (Arm)" Cc: "Vlastimil Babka (SUSE)" , Nico Pache , 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: Re: Process (was Re: [PATCH mm-hotfixes-unstable v18 00/14] khugepaged: add mTHP) collapse support Message-ID: References: <20260522150009.121603-1-npache@redhat.com> <506fed6b-8954-40fa-8b5e-c8bd8c0d004b@kernel.org> 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=us-ascii Content-Disposition: inline In-Reply-To: <506fed6b-8954-40fa-8b5e-c8bd8c0d004b@kernel.org> On Mon, Jun 01, 2026 at 05:45:30PM +0200, David Hildenbrand (Arm) wrote: > On 6/1/26 17:41, Lorenzo Stoakes wrote: > > On Sun, May 31, 2026 at 09:49:02PM +0200, David Hildenbrand (Arm) wrote: > >>> > >>> > >>> This I'm not so sure how it would work. Assuming we have submaintainers with > >>> their trees and branches, the final "stable branch" is merged from those. > >>> But it's not a good base for work targeting the same merge window, as that > >>> work would likely go to one of those submaintainer trees. But then it can't > >>> be based on the result of merge of all submaintainer trees. That could only > >>> work for patches targetting the next cycle (after the stable branch becomes > >>> part of rc1). > >>> > >>> So either patches can be based on rc1 and applied as topic branches in a > >>> submaintainer tree and then merged, or if they really depend on something > >>> already in a submaintainer tree, then based on the respective topic branch > >>> that's part of it. > >> > >> Right, most patches can be sent against the "stable branch", but cherry-picked > >> on a submaintainers branch / topic tree. > > > > I think life will be easier with submaintainer separate trees for this honestly > > :) or it could become a horrible mess in one tree I think. > > Requiring contributors to submit stuff targeted at some random trees is madness :) Err what? The 'random' tree is the MAINTAINERS entry you are targeting, it's based on the mm-next stable branch and only diverges in the work that's been done specific to the subtree, what's crazy exactly? I mean, is there any meaning to separate 'trees' at all if we just have one tree with topic branches in? Or are we going to have several parallel stable branches in one tree, and a bunch of maintainers with write access stepping on each other's toes? That sounds a lot more crazy to me, and I just don't think it's workable. > > > > > I think the simplest is what I suggested in reply to Vlasta, where each > > submaintainer tree has their own set of changes against mm-next/mm-stable and > > then we merge each week. > > Throw in hotfixes and it already starts being crazy. Again I really don't understand this? Hotfixes are a completely separate topic for one, I'm talking about ordinary development, but surely they're simpler aren't they? Everything's based on Linus's tree (so no confusion as to which tree), there shouldn't (hopefully) be a huge amount of them, and submaintainers can just potentially find a way to send them direct to mm-next anyway? > > > > > But am open to learning about what other subsystems in the kernel do... > > The TIP tree has a pretty elaborate model of dealing with topic branches, and > don't require things to be sent against specific topic branches. > > I'll try to understand that model. OK well, interested to hear about that. But also we should adapt what others do (which I think is very important to learn from obviously) against how mm works in practice. High review load with many overlapping changes might favour a different approach to a subsystem that looks different from that. > > -- > Cheers, > > David Thanks, Lorenzo