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 86183486403 for ; Thu, 24 Sep 2026 13:30:44 +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=1790256647; cv=none; b=a5e5yRF8/9J8eI+nkNTpT2zXTv09WoZglhPPGrN0YBeARKXWuVf81vg5Er8rRS6T1mJLYAiwNJZbO0khJ581QFTzhIa0XP85OvTxEsvehCQNRLxmKZmv6nwZLvIaEwK2XCaqH33MS9pDV4kFvIc7Psa7ZkpsYPaW/kv7bx2QirA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790256647; c=relaxed/simple; bh=7Fq+qkUCLkCfMyyrZgwy86Tk7HBipADDy2LDQdV7a4Y=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=N9AWQnCwP9OIm6/E5CFe5VqUk9ks+kOY6j3wd1/FPGMjaWaUnV1J4uWeR43UjqgKmPKF/QIHlBnGrAkn3iL25HfiYnFxmPAarC1LHR5Lu504hT7FAqLAN/uEiSko76oUqtH0qu26TNo/1LTCSuAkhYH79NWKxn/2j/7Qe7x4y4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CNKoEaGa; 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="CNKoEaGa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19E4D1F000FF; Thu, 24 Sep 2026 13:30:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790256642; bh=ksS44qBnYq4RuvOzi2REEzrBDOU9gIUJLPLEx7uVh8o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=CNKoEaGa8McLsZQLUfLJ/E8AvXFXxTOYcL3JHkzBXF8eDqfhXBJp0JvaN27XUxk1o RbVeyUcKr3AKxAq29jd6zhNlViFPy/KTdoJWxsbs81c73BGrB4O0t5CDnCk6fLMg2R tlj4F1jd4EkO/twfXYoKcdGxMOytpNo//sXsuFiDxjkTITdlC6G/sHy1iSy/CXZvi3 c/Fq3040HuX9Wuq0MYhYbUYsCDTgTMKCzUnkVbwwSNBHw6aDcufP9A69ZkdL5O+/db TOT+794TgI/zODq/64RvFMjHIzefJnvSdy8xz/KSY/f5k9NmufzpKivI/UYM7u0dQ0 ozJqaDXt3tyOg== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x9jX5-0000000D1mO-2SGs; Thu, 24 Sep 2026 13:30:39 +0000 Date: Thu, 24 Sep 2026 14:33:44 +0100 Message-ID: <875wzu4vuv.wl-maz@kernel.org> From: Marc Zyngier To: Matthias Goergens Cc: Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH] MAINTAINERS: name the kvmarm/kvmarm next branch In-Reply-To: <20260924083036.1744194-1-matthias.goergens@gmail.com> References: <20260924033536.3624334-1-matthias.goergens@gmail.com> <877bkb3zjq.wl-maz@kernel.org> <20260924083036.1744194-1-matthias.goergens@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: matthias.goergens@gmail.com, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 24 Sep 2026 09:30:36 +0100, Matthias Goergens wrote: > > On Thu, 24 Sep 2026 07:59:21 +0100, Marc Zyngier wrote: > > But that's not reflecting the way we deal with this tree. No actual > > development happens on that branch, as it is solely for integration. > > [...] > > Again, this is not how we work. We explicitly discourage patches > > against -next. The only sane reference to base kvmarm patches on is a > > published upstream tag from Linus' tree. > > Thanks for taking the time to explain; I'll drop this one and try to > leave out other integration-only trees. The rest will say only which > branch linux-next merges, not that patches should be based on it. > It does leave a question I'd like your view on. submitting-patches.rst > tells contributors to find the tree to base their work on through the > T: entry, and for KVM/arm64 that leads to a HEAD from 2020, while the Well, we can forward master to -rc1 when it lands. That's no big deal. > rule you describe isn't written down anywhere MAINTAINERS points to > (the entry has no P: profile). Would it help if the MAINTAINERS header > said that T: names where a subsystem's tree lives, and that the base > for patches can differ and belongs in the P: profile? I'm preparing > patches documenting T: anyway, so I could fold that in. Sure. Though that wouldn't help for kvmarm, as we don't have such a recorded profile. Documentation/process/maintainer-kvm-x86.rst could be used as a starting point, but there are some significant differences in the way we manage the tree, such as the absence of topic branches, the references to documentation, and of course the base for most patches. If someone feels the urge to write some documentation... M. -- Jazz isn't dead. It just smells funny.