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 F0A4A2D8379 for ; Tue, 2 Jun 2026 17:31:49 +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=1780421510; cv=none; b=R6FjzqTu3YT6B2Z6UPfG64IKvFIhAdCtc/MW7Spvi9y0MjMT+nlCLb69QNlLyMySNN5QsxTWfpX5i4kOv/PKz8gsA4A53cEAqDQNsKq6vwOLm+iqHL41T5WsO52Y4uDoW+PE4BTitAEibgeDXFTtzGoX4mpMSg/ov3ZGahT5xLc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780421510; c=relaxed/simple; bh=+QaLl7fiHwnP7l3EfkZnYECJ7VGnuMGdk7uY6Ni0rzA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=P4wp33pW4oHq1bliZoUkfjsWi928wZ413UE9HhdCspg02gdtsPRykGadtrIBdmxBrh2xLX4Jw+ZYyvpIbqDwYtaZJYLS2zCKoOzwb+mqTSKeiMMEgKZjk3C6+bdjDzKwiTjNcts8vcpBYGDUSAvLdzcMJLZDfOGPlz5YWqgxSPI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G3o6lrkA; 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="G3o6lrkA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CF911F00893; Tue, 2 Jun 2026 17:31:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780421509; bh=L7YoU2thqOqR9q4NL8fspTtdh+TCHHvtfVavmrm+Sho=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=G3o6lrkAn+/fVkI251MMo8MMjUTiQr9KTPberfX7b0Br8mtHbr0hsxJghBWOYpxzB +7GjrVCZv0SN0cykNtvyMpbnaAILWKNHk2DmSA6MtVG1l00+baBmKtU0X7vcNN68M2 tBEjhf0fORijaqupTeEtKY65t8CQHCCXR+h7H4wTOzxMosTVCU7tThyRLGzcgzriBq iFm90dyyU8L+45ZZi7rnQHAWcju9B/roRv1S8QDc5wUX0GBziulSNKBR0RAp/JGfyO +aMG6Vrfgvq/RmZyobjirgFQoieySCu6LwVWFjei/uzYpyGVInOU8lpArnAJJBeN5C Ls64ou6GY7GeQ== Date: Tue, 2 Jun 2026 20:31:42 +0300 From: Mike Rapoport To: "Vlastimil Babka (SUSE)" Cc: "David Hildenbrand (Arm)" , Lorenzo Stoakes , Nico Pache , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, liam@infradead.org, mhocko@suse.com, 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: <506fed6b-8954-40fa-8b5e-c8bd8c0d004b@kernel.org> <07334dc3-79ba-407e-96be-21ceb2eec00a@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <07334dc3-79ba-407e-96be-21ceb2eec00a@kernel.org> On Tue, Jun 02, 2026 at 02:55:30PM +0200, Vlastimil Babka (SUSE) wrote: > On 6/2/26 13:31, David Hildenbrand (Arm) wrote: > >>> 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. > >> Yeah, but as we said, we discussed, it's all rather complicated and we should > >> move incrementally. > >> > > > > Starting to read Documentation/process/maintainer-tip.rst, it's very interesting: > > > > “The tip tree is both a direct development tree and and an aggregation tree for > > several sub-maintainer trees.” > > > > “In general, development against the head of the tip tree master branch is fine, > > I don't think we'll be able to use this part as mm-next will be only an > aggreggation tree and not also a direct development tree. > > > but for the subsystems which are maintained separately, have their own git tree > > and are only aggregated into the tip tree, development should take place against > > the relevant subsystem tree or branch.” > > So it would have to be this. > As it might be hard for contributors to pick the right one (as Lorenzo > pointed out), we might in general suggest they try developing against rc1 > first (which is the common base of all subsystem trees), then either it > applies to one of the subsystem trees as-is, or it applies as a topic branch > (which starts also on the rc1 base) with reasonable conflict resolution > during merge, or we tell them which exising subtree/branch to rebase on. Unless we carry semi-baked work through merge window *, at rc1 all trees anyway restart the cycle. So basing new work on rc1 is very reasonable choice. Once that work is merged it will be merged to a particular sub-tree. Even patchsets that touch files across the trees still will be merged to a single sub-tree. And once a patches is merged it's clear what should be the base for the work that builds on top of that patchest. Obviously there would be conflicts when sub-trees are merged into the integration tree, but that's maintainers responsibility to resolve them IMHO. * Supposing we keep the model of early merging for testing [Lorenzo, don't yell at me ;-)] I think it's reasonable enough to drop everything that's not going upstream at, say, rc6 and ask contributors to rinse and repeat after rc1. > > “Bug fixes which target mainline should always be applicable against the > > mainline kernel tree. Potential conflicts against changes which are already > > queued in the tip tree are handled by the maintainers.” > > Ack. +1 -- Sincerely yours, Mike.