On Tue, Jun 18, 2019 at 11:22:55AM -0600, James Feeney wrote: > Uhm - could someone please "clue me in" here? > > When I look into: > > 'move all the pending queues back to their "real" places' > https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=c5da0df8985ac2f29ffdaba77bae201121bc0e10 No need to worry about that patch, that was done because my scripts normally assume specific directory locations of the patch queues, and I had to do a kernel release that did not include the existing pending patches. > I can find both the "d43c17ead879ba7c076dc2f5fd80cd76047c9ff4" patch, "HID: input: make sure the wheel high resolution multiplier is set" and the "39b3c3a5fbc5d744114e497d35bf0c12f798c134" patch, "HID: input: fix assignment of .value". > > I take this to mean that these patches are "in the stable-queue". But then, these patches are not "in the kernel". Yes. > So then, how do these patches go from being "in the stable-queue" to being "in the kernel"? I apply them when I do the release in a few hours/days. > To the "uninitiated" and "naive", as I am, to outward appearances, the > patches are "just sitting there". How do the patches get selected for > inclusion into the "next" kernel revision? I already selected them, sent emails saying they were selected and to what specific branches they were selected to. Then when the -rc releases happen so that people can do one final round of testing and object if I messed anything up, they get sent out again (which you responded to here.) If all goes well, when the "deadling" passes (usually 2 days +-2 days depending on stuff), I'll do a realease and apply the patches "for real" to the different kernel branches and cut a release. Then I start all over again... I understand that seeing a git tree of patches in a quilt series is odd, but it is very powerful and works very very well for what we do here. Does that help? greg k-h
