On Thu, 2023-01-12 at 11:56 +0000, Andre Przywara wrote: > On Thu, 12 Jan 2023 12:39:01 +0100 > Paolo Abeni <pabeni@xxxxxxxxxx> wrote: > > Hi, > > > On Thu, 2023-01-12 at 10:51 +0000, Andre Przywara wrote: > > > On Wed, 11 Jan 2023 21:31:43 -0800 Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > > Hm, we have a patch in net-next which reformats the entries: > > > > ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b > > > > > > > > Would you like this ID to be also added in stable? We could just > > > > apply it to net, and deal with the conflict locally. But if you > > > > don't care about older kernels then better if you rebase. > > > > > > Stable would be nice, but only to v6.1. I think I don't care > > > about older kernels. > > > So what about if I resend this one here, based on top of the reformat > > > patch, with a: > > > Cc: <stable@xxxxxxxxxxxxxxx> # 6.1.x > > > line in there, and then reply to the email that the automatic backport > > > failed, with a tailored patch for v6.1? > > > Alternatively I can send an explicit stable backport email once this one > > > is merged. > > > > Note that we can merge this kind of changes via the -net tree. No > > repost will be needed. We can merge it as is on -net and you can follow > > the option 2 from the stable kernel rules doc, with no repost nor > > additional mangling for stable will be needed. > > > > If you are ok with the above let me know. > > That sounds good to me, but that will then trigger a merge conflict when > net-next (with the reformat patch) is merged? I guess it's easy enough to > solve, but that would be extra work on your side. If you are fine with > that, it's OK for me. Fine by us (well, probably poor Jakub will end-up handling the conflict, but AFAIK he is ok with this specific case). I'll merge the patch on net. Cheers, Paolo
