On Tue, 25 Jun 2024, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > 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. To be fair, this one seems to have been an accident. The same commit was cherry-picked to *two* different branches by two different people [1][2], and this is something we try not to do. Any cherry-picks should go to one tree only, it's checked by our scripts, but it's not race free when two people are doing this roughly at the same time. BR, Jani. [1] https://lore.kernel.org/r/Zjz7SzCvfA3vQRxu@fedora [2] https://lore.kernel.org/r/c3rduifdp5wipkljdpuq4x6uowkc2uyzgdoft4txvp6mgvzjaj@7zw7c6uw4wrf -- Jani Nikula, Intel
