On 11 October 2018 at 21:52, Michael Clark <m...@sifive.com> wrote: > Peter, I have to pull in your remote wholesale. I don't cherry-pick from > your tree. I think this is truly dumb. This might serve the needs of some > folk running Linux but we have emulation fidelity fixes for the RISC-V > community as a whole. Alastair is the only person not submitting his patches > via the (sub)maintainer tree. BTW Who is the RISC-V port maintainer? > Puzzled.
I don't particularly mind who among you RISC-V folk does the QEMU submaintainer work. But I would like to see somebody doing it, and sitting on all your patches indefinitely in an out-of-tree fork is not doing that job. There is no obligation to work with upstream on a RISC-V QEMU, of course. But your last pull request was back in May, so it's not surprising if other people offer to step into that gap. If you have emulation fidelity fixes, then the best approach is to work on getting them upstream. If you have downstream consumers for whom you want to maintain a validated definitely-works tree, that's great. How you manage that downstream tree (when you rebase it, what you put in it, whether you make it have formal "releases", etc) is up to you. I would suggest that trying to make it be the same thing as your development tree for pushing work upstream is not likely to serve either purpose well, though. The expected patch flow for QEMU is: * original patch author posts patch to qemu-devel (this applies also if the author happens to be the submaintainer) * patch gets reviewed on this mailing list, by you or anybody else * patches relevant to risc-v get collected up by the submaintainer * submaintainer submits those patches via pull request (with a frequency usually about every two weeks, more often if volume of patches merits it) > Here is the pull queue. But I'm not ready to make a PR until we have the CI > running the regression. This phrasing suggests you might be thinking about making a large batch pull request all at once close to the freeze deadline. That would be a bad idea -- it did not work well last release either. Patches are best dribbled into upstream at a steady pace as they are written. (Note also that pull requests should not contain patches which have not already been posted to qemu-devel and reviewed here.) thanks -- PMM