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 B245B3DB30F for ; Mon, 1 Jun 2026 15:41:16 +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=1780328480; cv=none; b=aLUELJ0St87Ad18mkm121MJvGwlZkVU73aaUn7nyJ/44qkRn3gSvTLYQrUG/enqAgCPsKBOm+uL6yd7heUnV0jEUtl2A/8FgWYVNYUutVmmF5qnkqSNCORnzEPfDusF5Kj4DX/tsYRnS7e2jPUqWNUAgaAQw0ZBXWVOxE4oRmmI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780328480; c=relaxed/simple; bh=CXGE/ImL3LG9ug1N+zBj+qfgDjTtJ0SFhuDhOcVyA3g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Mx30N5ljUgrXgasnzJBG9uiheUasi6llPbStxBv6XbATs+ETOa6WTrF7r6xQjl8Cbw10xvRdUhIGERhly6RGcyfysSqm94pHpjDkyFXOmmF6Z3iKXfAG4iqYcRxUtHvk9SDIsaJCKzDaFuB04tPYupV8eUHj708poQqVVrboCIY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TIHofZok; 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="TIHofZok" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AE711F00899; Mon, 1 Jun 2026 15:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780328476; bh=CXGE/ImL3LG9ug1N+zBj+qfgDjTtJ0SFhuDhOcVyA3g=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=TIHofZokpd2Slil/bA0ZEHOxLelS6irz+s7ICShUyFLNrc678BtfBukvOF2CdXkpi +fg8LqZO3Il9ZcVizYaC8fTHj7MtmUGkYBv1MEQBkqQfoxReiRfZd9yl1PLJl1Z0Yn ySf/IO+xYYd0dv5WyuUll8uodZgb6NQAodyH7k0N1H62KQRKBwgyqk70J1ipj3IMqi gejDaaCW5w3w3f8xhjISs7rGliGApuZtCe7u7Xq4QH2tqx6e5CgFKHFCpRktAdJeqi CK/ES3fOC14daidB/O6GQoJibMBtEL6YICr/1Lr+fKoOLrvSjIRUS174/i0LZRUCbt Xq9ClzbOm3Y1w== Date: Mon, 1 Jun 2026 16:41:10 +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> 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: On Sun, May 31, 2026 at 09:49:02PM +0200, David Hildenbrand (Arm) wrote: > > > >> and have people > >> base work against that? > > > > 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. 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. But am open to learning about what other subsystems in the kernel do... > > > > > >> This would be 'source of truth' and what we eventually send to Linus. > > > > Yes. > > > >> In that world, the maintainers perform conflict resolution, but with git rerere > >> we need only do this once. > > > > I think the conflicts would arise from merging the submaintainers' branches > > to the mm-next tree, and if they get updated and the merges are recreated > > (like linux-next works) git rerere avoids resolving the same conflicts again. > > > > Hm like Andrew said, this needs a diagram indeed :) > > It's one of the first things we'll discuss in the upcoming meetings ... I want > to talk to some other folks (in particular, TIP and KVM) to understand how they > are handling that. Yes let's definitely see what works for others and use that to figure things out. > > Hopefully I'll find some time after my inbox calmed down a bit ... jeez, 1500 > mails in one week if my eyes didn't betray me. Yeah, it's crazy again lately... > > -- > Cheers, > > David Cheers, Lorenzo