From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [85.220.165.71]) (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 6D17A1118B for ; Mon, 19 Jun 2023 13:59:24 +0000 (UTC) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qBFPa-0005Ly-J3; Mon, 19 Jun 2023 15:59:18 +0200 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtp (Exim 4.94.2) (envelope-from ) id 1qBFP9-008WgL-AE; Mon, 19 Jun 2023 15:58:51 +0200 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.94.2) (envelope-from ) id 1qBFP8-00FbzI-5U; Mon, 19 Jun 2023 15:58:50 +0200 Date: Mon, 19 Jun 2023 15:58:49 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Maxime Ripard Cc: 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 , Steven Price , Sumit Semwal , Jerome Brunet , linux-samsung-soc@vger.kernel.org, Robert Foss , Karol Herbst , Samuel Holland , Kevin Hilman , =?utf-8?B?TWHDrXJh?= Canal , Javier Martinez Canillas , Kuogee Hsieh , Xinliang Liu , Danilo Krummrich , NXP Linux Team , Miaoqian Lin , linux-sunxi@lists.linux.dev, Rob Clark , Rahul T R , Raphael Gallais-Pou , Jani Nikula , Sascha Hauer , etnaviv@lists.freedesktop.org, Stephen Boyd , Inki Dae , Alain Volmat , 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 , Jonathan Hunter , linux-rockchip@lists.infradead.org, Ben Skeggs , Russell King , Jessica Zhang , linux-mips@vger.kernel.org, Liu Ying , linux-arm-msm@vger.kernel.org, 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 , linux-mediatek@lists.infradead.org, Brian Starkey , Kuninori Morimoto , Yuan Can , Stefan Agner , Michal Simek , linux-tegra@vger.kernel.org, Laurent Pinchart , Andrzej Hajda , Sam Ravnborg , Rob Herring , Chen-Yu Tsai , Jernej Skrabec , Xinwei Kong , Mali DP Maintainers , Joel Stanley , nouveau@lists.freedesktop.org, Orson Zhai , Chun-Kuang Hu , Lyude Paul , Arnd Bergmann , Guo Zhengkui , Konrad Dybcio , Alison Wang , Abhinav Kumar , Christian Gmeiner , Mark Brown , Baolin Wang , Daniel Vetter , Liu Shixin , Tomi Valkeinen , Deepak R Varma , Karol Wachowski , Kieran Bingham , Ricardo Ribalda , Tian Tao , Shawn Guo , Yannick Fertre , linux-stm32@st-md-mailman.stormreply.com, Emma Anholt , Liviu Dudau , Alexandre Torgue , Doug Anderson , Paul Cercueil , Laura Nao , David Airlie , Marek Vasut , linux-renesas-soc@vger.kernel.org, Yongqin Liu , Jayshri Pawar , Jonas Karlman , Russell King , Martin Blumenstingl , Philippe Cornu , Thomas Zimmermann , Melissa Wen , Christophe JAILLET , Fabio Estevam , Laurentiu Palcu , Matthias Brugger , AngeloGioacchino Del Regno , Bjorn Andersson , Nicolas Ferre , Krzysztof Kozlowski , Qiang Yu , Philipp Zabel , 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: <20230619135849.crbbeqsytla7upbw@pengutronix.de> References: <20230601154002.uv2wfatpb7b45duz@pengutronix.de> <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="tz4xugcktzhvzxbs" Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-sunxi@lists.linux.dev --tz4xugcktzhvzxbs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Maxime, On Mon, Jun 19, 2023 at 02:47:09PM +0200, Maxime Ripard wrote: > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K=F6nig wrote: > > 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. >=20 > 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. It seems not to be rigorously enforced, but it exists. See for example https://lore.kernel.org/all/20230510092313.16693e4c@canb.auug.org.au/ . @Stephen: you wrote there You will need to ensure that the patches/commits in your tree/series have been [...] destined for the current or next Linux merge window. This is a bit ambiguous because (AFAIK) during a merge window no patches should be added that are supposed to go in during the next one, right? Maybe adapt your template to read: [...] destined to be included in the next -rc1 release. which is more precise? Even if others don't adhere to it, IMHO it's still an opportunity to improve. Also there is a difference between a patch that is included in next that doesn't make it in during the next merge window and a patch that disappears from next. The latter (up to now) only happened to me when there was a problem with the patch and the maintainer who first thought the patch to be fine changed their opinion. > > > > For me, if a maintainer puts some patch into next that's a statement > > > > saying (approximately) "I think this patch is fine and I intend to > > > > send it to Linus during the next merge window.". > > >=20 > > > I mean, that's what we're saying and doing? > >=20 > > 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 are: > >=20 > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or >=20 > 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. We're mixing two things here. One is: "When will my patches be merged?". I have no problem being patient here and b) is fine for me. The other is "The patches first being included in next and then later not anymore is a thing that just waits to be misinterpreted". This latter is the one I care about here and that I think should be fixed for the future. > > b) keep c2807ecb5290 in a branch that doesn't result it entering next > > before v6.5-rc1. >=20 > All the drm-misc committers use dim. If that's a concern for you, feel > free to send a patch addressing this to dim. Not sure this is sensible given that I neither use nor know dim. Also I think it should be the drm-misc maintainers who should care here given that it's them who create this unfortunate situation again and again. > > > > So my expectation is that if a patch is dropped again from next, th= ere > > > > was a problem and it would be fair if the maintainer tells the > > > > author/submitter about this problem and that the patch was dropped. > > >=20 > > > But it wasn't dropped, > >=20 > > From my POV it was dropped from next as it was part of next between > > next-20230609 and next-20230615 but not any more since next-20230616. > > You talk about (not) being dropped from some branch in drm-misc, that's > > irrelevant for the thing I'm complaining about. >=20 > You were never told that they were merged in linux-next, but in > drm-misc-next. That's nitpicking and little helpful here. In your bubble where only or mostly drm-misc matters it's ok to only look at drm-misc. But for a contributor who sends patches for dozens of subsystems next is the more useful place to look and each subsystem that is special is an obstacle. =20 > If they did, it's mostly an unfortunate artifact. I see some progress in this discussion as you seem to agree this is unfortunate. Actually that's all I intend to achieve. > We have a documentation that explains the process and how drm-misc-next > works. If that's still confusing somehow, feel free to amend it to make > it clearer. >=20 > > > it's still very much to be sent to Linus during the next merge window. > >=20 > > "next merge window" as in the one leading to 6.5-rc1? Either we mean > > different things when we say "next merge window", or there is a > > misunderstanding I don't see yet. >=20 > Linus doesn't want to receive in a PR patches that haven't been in > linux-next for at least two weeks. In most cases that's rc6, which means > that by the time we send our last PR before rc6, the > next-merge-window-while-still-meeting-Linus-requirements is 6.6. >=20 > The rule applies to all trees, and it's why the soc tree also requires > its submaintainers to submit their PR before -rc6. >=20 > 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. Not knowing dim I think there is a simple(?) technical solution here: It only has to make sure that after the pull request from drm-misc to drm was sent, no new patches are added to the branch that is merged in next. Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --tz4xugcktzhvzxbs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmSQXxkACgkQj4D7WH0S /k7hFwf9Hc6jU21nCSnyxtSJD52rcy1CAVfRQuE4L4puvv1qo23YedPDQWx38LRO 5IlKdBKcRSupHJH/eZnSoodize/BLrnMvfjU6GBpk7iQJZ5ecRYBP4qOncVQT8xC b/mFFWcVkhM7dnKm7PhHsBgB2VpeX2ldgXeSUYZGo3T+vhcP3nloyAedR2fSNSSG dmZoZhftQSafs3ek8qnVMBdTzJAobbe+P/EhtAR32YOdZRueccgkQ48/WJRGDC9l bzMhHuw5SAAq3XpOk3JN5cL2AK7yB7IDH/SzDVUUSe+DRTT6BwohuGTuYlgfVoPE 2vFPvvwGcWpLmgrrXZWNtM8jn9usBg== =9IX/ -----END PGP SIGNATURE----- --tz4xugcktzhvzxbs--