From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 5EFBAE576 for ; Mon, 19 Jun 2023 14:02:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F02FBC433C8; Mon, 19 Jun 2023 14:02:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687183366; bh=aoZIdKtakof1RrLG1uHfgHvEnjV5bAZA/iEPAGIdL1U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jV95SsXCscon9mjIrA85S4h2EdhGBkgNuFn8VZOUrDV+lIkF0pUNayXcf0CKyi8A6 N48rXJ2wuubn0Bti2ZkKUiijVrVqJoWAxGylrGc2P/8z2dpERee9fF4Un0UHHbArW4 auoHmiA8vzTlS8TEVa4jO3sKRu3sb8gHf+zbcrBovj5dR8bhFUe8fIUCFrs8zNtGMM a8tAV38SZ7gAwjXhA1JwM4LL2kusu0pUESpxODTU+LmevESt4iijRlQuZNuPIRrx6/ xEJ/A1HJ21okj5noJ5wg00TGmdIesmam9MZrNHImWINT+iaS1huZnX+m6jmzDi4WVy eOUJrD/hLSISQ== Date: Mon, 19 Jun 2023 16:02:43 +0200 From: Maxime Ripard To: Geert Uytterhoeven Cc: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Raymond Tan , Heiko =?utf-8?Q?St=C3=BCbner?= , Akhil P Oommen , Linus Walleij , dri-devel@lists.freedesktop.org, Stanislaw Gruszka , Alim Akhtar , Anitha Chrisanthus , Marijn Suijten , Jonathan Hunter , Sumit Semwal , Jerome Brunet , linux-samsung-soc@vger.kernel.org, Robert Foss , Kuninori Morimoto , Samuel Holland , Kevin Hilman , =?utf-8?B?TWHDrXJh?= Canal , Javier Martinez Canillas , Kuogee Hsieh , Xinliang Liu , Danilo Krummrich , NXP Linux Team , linux-sunxi@lists.linux.dev, Rahul T R , Raphael Gallais-Pou , Jani Nikula , Sascha Hauer , etnaviv@lists.freedesktop.org, Yuan Can , Inki Dae , Jessica Zhang , Sean Paul , Johan Hovold , Hyun Kwon , Andrew Jeffery , Jingoo Han , Seung-Woo Kim , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , kernel@pengutronix.de, Alex Deucher , freedreno@lists.freedesktop.org, Claudiu Beznea , Alexandre Belloni , linux-aspeed@lists.ozlabs.org, Tomi Valkeinen , Thierry Reding , John Stultz , Mihail Atanassov , Liang He , Ville =?utf-8?B?U3lyasOkbMOk?= , lima@lists.freedesktop.org, Chunyan Zhang , Alexey Brodkin , Minghao Chi , Steven Price , linux-rockchip@lists.infradead.org, Ben Skeggs , Russell King , Alain Volmat , Liu Ying , linux-arm-msm@vger.kernel.org, Nicolas Ferre , Wang Jianzheng , linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Neil Armstrong , Boris Brezillon , Sandy Huang , Paul Kocialkowski , Kyungmin Park , Maxime Coquelin , Christophe JAILLET , Brian Starkey , Karol Herbst , Miaoqian Lin , Stefan Agner , Michal Simek , Matthias Brugger , Laurent Pinchart , Andrzej Hajda , Sam Ravnborg , Rob Herring , Xinwei Kong , Jernej Skrabec , Chen-Yu Tsai , Mali DP Maintainers , Joel Stanley , nouveau@lists.freedesktop.org, Orson Zhai , Philipp Zabel , Chun-Kuang Hu , Lyude Paul , Arnd Bergmann , Guo Zhengkui , Liviu Dudau , Alison Wang , Abhinav Kumar , Christian Gmeiner , Mark Brown , Baolin Wang , Paul Cercueil , Tomi Valkeinen , Deepak R Varma , Karol Wachowski , Kieran Bingham , Ricardo Ribalda , Tian Tao , Shawn Guo , Bjorn Andersson , linux-stm32@st-md-mailman.stormreply.com, Emma Anholt , Konrad Dybcio , Alexandre Torgue , Doug Anderson , Liu Shixin , Krzysztof Kozlowski , Laura Nao , David Airlie , Marek Vasut , linux-renesas-soc@vger.kernel.org, Yongqin Liu , Jayshri Pawar , Jonas Karlman , Russell King , Martin Blumenstingl , Qiang Yu , Thomas Zimmermann , Melissa Wen , linux-mediatek@lists.infradead.org, Fabio Estevam , Laurentiu Palcu , linux-tegra@vger.kernel.org, Stephen Boyd , AngeloGioacchino Del Regno , Yannick Fertre , linux-mips@vger.kernel.org, Rob Clark , Philippe Cornu , Daniel Vetter , Dmitry Baryshkov , Jyri Sarha , Lucas Stach , Stephen Rothwell Subject: Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void Message-ID: References: <20230617161222.wy55pbomnrrlfy5u@pengutronix.de> <20230618123915.hmy66z7e532jhwgk@pengutronix.de> <20230618162950.6th2yo66baqay5mv@pengutronix.de> <20230619105342.ugf5gz26gcalcsi6@pengutronix.de> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="g5vgywptxejmww6t" Content-Disposition: inline In-Reply-To: --g5vgywptxejmww6t Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, >=20 > CC sfr >=20 > On Mon, Jun 19, 2023 at 2:51=E2=80=AFPM Maxime Ripard wrote: > > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K=C3=B6nig wrote: > > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote: > > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K=C3=B6nig wro= te: > > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote: > > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K=C3=B6nig= wrote: > > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote: > > > > > > > > On Sat, Jun 17, 2023 at 9:15=E2=80=AFAM Uwe Kleine-K=C3=B6n= ig > > > > > > > > wrote: > > > > > > > > > Together with the patches that were applied later the top= most commit > > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to p= latform remove > > > > > > > > > callback returning void"). This commit was part for the f= ollowing next > > > > > > > > > tags: > > > > > > > > > > > > > > > > > > $ git tag -l --contains c2807ecb5290 > > > > > > > > > next-20230609 > > > > > > > > > next-20230613 > > > > > > > > > next-20230614 > > > > > > > > > next-20230615 > > > > > > > > > > > > > > > > > > However in next-20230616 they are missing. In next-202306= 16 > > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b986392867= 00a35088660. > > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops= 37 (that are > > > > > > > > > also not included with a different commit id). The 37 pat= ches dropped > > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb529= 0: > > > > > > > > > > > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb= 4384aa9dc..c2807ecb5290 > > > > > > > > > 1 Christophe JAILLET > > > > > > > > > 2 Jessica Zhang > > > > > > > > > 5 Karol Wachowski > > > > > > > > > 1 Laura Nao > > > > > > > > > 27 Uwe Kleine-K=C3=B6nig > > > > > > > > > 1 Wang Jianzheng > > > > > > > > > > > > > > > > > > > > > > > > > > > I guess this was done by mistake because nobody told me a= bout dropping > > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into = drm-misc-next > > > > > > > > > again? > > > > > > > > > > > > > > > > Actually, it was probably a mistake that these patches got = merged to > > > > > > > > linuxnext during the 4 days that you noticed. However, your= patches > > > > > > > > aren't dropped and are still present in drm-misc-next. > > > > > > > > > > > > > > > > drm-misc has a bit of a unique model and it's documented fa= irly well here: > > > > > > > > > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc= =2Ehtml > > > > > > > > > > > > > > Is there a flaw then in this unique model (or its implementat= ion) when > > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? T= his isn't > > > > > > > expected, is it? > > > > > > > > > > > > There's no expectation afaik. Any tree merged in linux-next can= be > > > > > > rebased, drop a patch, amend one, etc. without any concern. > > > > > > > > > > I agree that there are no rules broken for a tree that is include= d in > > > > > next and a maintainer is free to rewrite their tree independant o= f the > > > > > tree being included in next. > > > > > > > > > > Still I think that shouldn't be used as an excuse. > > > > > > > > As an excuse for what? > > > > > > Just because the rules for trees in next allow the merged branch to be > > > rewritten, shouldn't be used to justify rewriting the branch. > > > > > > IMHO you still should ensure that only commits make it into any next > > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you > > > intend to be included in X-rc1. > > > > That's never been a next rule either. Rust support has been in next for > > almost a year without being sent as a PR for example. >=20 > https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Pr= ocess.rst#L297 >=20 > "The linux-next tree is, by design, a snapshot of what the mainline > is expected to look like after the next merge window closes." >=20 > The general rule for linux-next is that its contents are intended to end > up in the next kernel release, and that it should not contain commits > that are intended for the next-next release, cfr. what Stephen sends > out to new trees: >=20 > "You will need to ensure that the patches/commits in your tree/series = have > been: > [...] > * destined for the current or next Linux merge window." >=20 > and what he requests regularly in his announces, e.g.: >=20 > "Please do not add any v6.4 related commits to your linux-next included > branches until after v6.3-rc1 has been released." Which is why those patches aren't in next anymore. > AFAIU, the exception to the rule is new, self-contained, and sometimes > controversial development, which may have to cook for a few more cycles, > if it ends up in a PR at all. >=20 > > > > > For me, if a maintainer puts some patch into next that's a statem= ent > > > > > saying (approximately) "I think this patch is fine and I intend to > > > > > send it to Linus during the next merge window.". > > > > > > > > I mean, that's what we're saying and doing? > > > > > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as= it > > > was part of next-20230609). A few days later however the patches were > > > dropped. > > > > > > The two options that would have made the experience smoother for me a= re: > > > > > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or > > > > That's not an option. You were simply too late for v6.5-rc1, unless you > > expect us to get rid of timezones and work on week-ends. But surely you > > don't. >=20 > I don't think anyone expects you to do that... >=20 > > > b) keep c2807ecb5290 in a branch that doesn't result it entering next > > > before v6.5-rc1. > > > > All the drm-misc committers use dim. If that's a concern for you, feel > > free to send a patch addressing this to dim. >=20 > So you say this is an issue with the tooling? ;-) > If the tooling breaks the rules, perhaps the tooling should be fixed? We've been using dim for more than 5 years. It doesn't seem to work too bad? And it does feel like the goalposts are moving there: the discussion started by "you shouldn't rebase a tree" and is now at "patches should never be in a next branch if they can't reach the next merge window, even though it's not apparent yet" But yeah, I now that complaining about how much drm-misc sucks is fun and all, but it's still not clear to me what a potential solution to this would be? Knowing that we can't rebase or close drm-misc-next, and that it should be automated in dim somehow, what would that fix be? > > So yeah, sorry if it was confusing. At the end of the day, it's a > > compromise, and I can't find a better one for everyone involved > > (maintainers, contributors and committers alike) off the top of my head. >=20 > As I understand, the main issue Uwe is objecting to, is that his > patches ended up in linux-next first, only to be dropped again from > linux-next later, and that there was no communication about the > latter. >=20 > If you're not constantly working on a subsystem, it can be very hard > to keep track of the status of your own drive-by patches. When patches > get applied, appear in linux-next, and disappear from linux-next again > later, it's worse... Sure, I've worked with enough of these series to understand how it can be annoying. Maxime --g5vgywptxejmww6t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZJBgAwAKCRDj7w1vZxhR xbHrAQC2tbpr59FvWgo5UdT6HVaFbQ1eIt6cd77EE73rYdv7cQD7B85ixe8k46Oo fLEiK8/0rTPKuTVzkjY164VJRmNDYQ0= =LBiM -----END PGP SIGNATURE----- --g5vgywptxejmww6t--