On Fri, Dec 22, 2023 at 3:21 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > > I see it's not, I'm asking if it should be - given the latencies > > > involved it seems like it'd be helpful for keeping -next working. > > > This is on purpose. We use -next for, well, the next release, > > and not as a band-aid for some other purpose. If you think things > > Note that -next includes pending-fixes which is specifically for the > purpose of getting coverage for fixes intended to go to mainline (indeed > this issue was found and reported before the original problematic patch > was sent to mainline, it's not clear to me what went wrong there). Indeed most other KVM architectures have a tree included in linux-next's pending-fixes and kvm/master is included in there. Knowing that KVM/ARM does not have a fixes tree included in linux-next might make me get those in kvm/master a bit faster, but then I'd let them stay in kvm/master, for a day or two of soaking in linux-next. It's never happened to me to send broken or conflicting pull requests after -rc1, as far as I remember, and it's indeed unlikely, but linux-next does provide a little bit of peace of mind. > He is on CC here. I'm not sure that it's specifically things not > getting merged (well, modulo this one fixing an issue in mainline) - I'm indeed not exactly a speed demon, but in this case I specifically wanted to make sure to include everything posted before Christmas, as this was likely going to be the last PR in the release. I also wouldn't have minded a review or tested-by for https://www.spinics.net/lists/kvm/msg335755.html :) but in the end I included it in the pull request anyway. Paolo
