On Tue, Jun 25, 2024 at 08:03:33AM -0400, Rodrigo Vivi wrote: > 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 Done. > > 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. Please tell me how to do so. > But I do understand that any change like this would cause a 'latency' > on the scripts and slow down everything. Depends, I already put a huge latency on drm stable patches because of this mess. And I see few, if any, actual backports for when I report FAILED stable patches, so what is going to get slower than it currently is? > > Why not, what went wrong? > > worst thing in this case is that git applied this cleanly, although > the change was already there. Yup. > 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. Normally you all tag these cherry-picks as such. You didn't do that here or either place, so there was no way for anyone to know. Please fix that. > > 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)? Intel trees have traditionally been the worst, but normally you all give me some cherry-pick clue on the commits so I can weed them out. That didn't happen here. But, I will note that the AMD drm tree is now starting to do this, in much worse ways than the Intel tree because there is NO cherry-pick information anywhere, so again, I have no idea what to do and massive conflicts happen. So AMD is copying your bad behavior, please, both of you stop and fix this so that it isn't so broken. Again, I understand the need/want to have multiple versions of the same patch in different branches to get fixes merged quicker, but when you do that, please give me a way to determine this, otherwise we have no chance. thanks, greg k-h
