On Tue, Jun 25, 2024 at 03:41:24PM +0300, Jani Nikula wrote: > 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. any cherry-pick SHOULD have the git id referenced when they are cherry-picked, that's what the id is there for. Please always do that. greg k-h
