> >> > > Was this rejected? > >> > > Any resolution on this (ACK or NAK) would be useful. Thanks! > >> > > >> > They are in our "to get to" queue, which is very long still due to > >> > multiple conferences and travel. > >> > > >> > But I will note, you didn't put the git id of the patches in the patches > >> > themselves, so it will take me extra work to add them there when > >> > applying. > >> > > >> > Also, why just 6.1? What about newer stable kernels? You can't update > >> > and have a regression, right? > >> > >> Note, because of this, we can not take these patches now at all anyway :( > > > >Because without any knowledge of whether these patches would even be > >accepted into stable, or whether they would need to go in via ACK, > >preparing them for more trees seemed like pointless busywork... > > FWIW, the above just means that we get to do the busywork rather than > the submitter... We're certainly willing to do the work, but we're not entirely sure what you want, and whether you will indeed even accept these patches... We're just trying to be mindful of everyone's time... For example as a reviewer myself I know that in many cases it is simply easier to do the clean (!) cherrypick yourself (you presumably have scripts that automate the entire thing), rather than try to verify that someone else's cherrypick is actually indeed clean. These patches cleanly cherry pick, build, and pass our tests on current 6.5 and 6.1 LTS. git checkout remotes/linux-stable/v6.5.6 && git cherry-pick 1671bcfd76fdc0b9e65153cf759153083755fe4c && git cherry-pick 5027d54a9c30bc7ec808360378e2b4753f053f25 && git cherry-pick 5cb249686e67dbef3ffe53887fa725eefc5a7144 && run_uml_ack_net_test (and same thing with 6.1.56) Do you simply want the upstream sha1s? Or do you want us to follow up with patches? The situation gets more complex with 5.15 and older: In this particular case, there are 3 patches, they could (and maybe even should?) be squashed into 1 patch for <=5.15 stable. Greg didn't like that - I get why - I don't have an opinion here. But it does result in complexities... for example: one of the patches adds to UAPI (and cannot be trivially cherrypicked to older kernels because the enum needs previous enums to be added first), and then the next patch renames it... There's no clear obviously correct thing to do here, there's at least a few possibilities: (a) 4 patches: the first has no upstream equivalent and simply fast forwards the enum to the point where the next apply, 3 as clean as possible backports follow up (b) 3 patches, the first one squashes in all the uapi enum fast forwarding - including the patch that renames the UAPI constant (c) just a single squashed patch (d) we could also cherrypick without the UAPI portions... they're not terribly important... (e...) maybe other ways I've missed Thanks, - Maciej
