On Wed, Jun 19, 2024 at 04:16:56PM +0200, Greg Kroah-Hartman wrote: > On Wed, Jun 19, 2024 at 04:03:29PM +0200, Francois Dugast wrote: > > On Wed, Jun 19, 2024 at 02:53:52PM +0200, Greg Kroah-Hartman wrote: > > > 6.9-stable review patch. If anyone has any objections, please let me know. > > > > Hi Greg, > > > > This patch seems to be a duplicate and should be dropped. Please also drop the 6.9.7-rc1: https://lore.kernel.org/stable/20240625085557.190548833@xxxxxxxxxxxxxxxxxxx/T/#u > > How are we supposed to be able to determine this? > > When you all check in commits into multiple branches, and tag them for > stable: and then they hit Linus's tree, and all hell breaks loose on our > scripts. "Normally" this tag: > > > > (cherry picked from commit 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de) > > Would help out here, but it doesn't. I wonder if there would be a way of automate this on stable scripts to avoid attempting a cherry pick that is already there. But I do understand that any change like this would cause a 'latency' on the scripts and slow down everything. > Why not, what went wrong? worst thing in this case is that git applied this cleanly, although the change was already there. But also a timing thing. The faulty patch was already in the master. At the moment we applied the fix in our drm-xe-next, we had already sent the latest changes to the upcoming merge-window, so it propagated there as a cherry-pick, but we had to also send to the current -rc cycle and then the second cherry-pick also goes there. This fast propagation to the current active development branch in general shouldn't be a problem, but a good thing so it is ensured that the fix gets quickly there. But clearly this configure a problem to the later propagation to the stable trees. > > I'll go drop this, but ugh, what a mess. It makes me dread every drm > patch that gets tagged for stable, and so I postpone taking them until I > am done with everything else and can't ignore them anymore. > > Please fix your broken process. When you say drm, do you have same problem with patches coming from other drm drivers, drm-misc, or is it really only Intel trees? (only drm-intel (i915) and drm-xe)? > > greg k-h
