Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches

[Palmer Dabbelt]

On Fri, 12 Oct 2018 02:34:12 PDT (-0700), address@hidden wrote:
> On 11 October 2018 at 21:52, Michael Clark <address@hidden> 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.

I agree.  I think the best bet here is to just start picking through the 
patches and submitting those that we have high confidence in -- there's a 
handful of known bugs that have been fixed in Michael's tree.

> 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)

This makes sense.  It's almost exactly the Linux flow, which I'm used to and I 
have down to a fairly mechanical process.  I think the real issue here is that 
we don't have anyone who has officially committed to doing this, so I'm just 
going to pull the trigger and say I'm doing so.

My Linux PR flow is to tag a PR on Mondays, send it out to the list for 
comments, and then if it passes muster to submit an official PR on Wednesdays.  
It's been working smoothly (we've yet to have to kill a PR), so I think I'll do 
the same thing for QEMU except I'll do Tuesday/Thursday.

I talked to Michael on the phone late last week and he seemed OK with this.

> > 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