Ping. On Fri, May 7, 2021 at 8:46 AM Doug Evans wrote: > On Fri, May 7, 2021 at 8:23 AM Marc-André Lureau < > marcandre.lureau@gmail.com> wrote: > >> Hi >> >> [...] >>> >>> >>> Changes from v5: >>> >>> 1/4 slirp: Advance libslirp submodule to current master >>> NOTE TO REVIEWERS: It may be a better use of everyone's time if a >>> maintainer takes on advancing QEMU's libslirp to libslirp's master. >>> Beyond that, I really don't know what to do except submit this patch as >>> is currently provided. >>> >>> >> Reviewed-by: Marc-André Lureau >> >> It can do, but it should rather be a diff of the commits that are new, >> those that were not in the stable branch. >> > > > Can you elaborate? > E.g., Should a new libslirp release be made first, and then update > qemu-master to that new release? > Hey Marc-André and Samuel, What's the next step here (if any)? Would it be preferable to make a new libslirp release instead? [I also don't understand the comment "it should rather be a diff of the commits that are new, ...". I haven't seen this request before (apologies if I missed it), but more importantly isn't it trivial to generate such diffs, without adding them to the email? I could be missing something of course.] At some point a new libslirp release needs to be made, and at some point QEMU needs to be updated to use it. Seems like now is a good time, but maybe there are reasons to prefer not doing so now. I can imagine QEMU wanting to always use a stable branch of libslirp, so I just want to be absolutely clear that switching QEMU to use libslirp's master branch is desired, and if anything more is needed from me. I'm happy with whatever you decide, but I don't want to waste your time guessing and then having to iterate when I guess wrong.