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

[Michael Clark]

Hi All,

On Thu, Oct 11, 2018 at 7:22 AM Palmer Dabbelt <address@hidden> wrote:

> On Wed, 10 Oct 2018 11:10:07 PDT (-0700), address@hidden wrote:
> > On 10 October 2018 at 18:49, Palmer Dabbelt <address@hidden> wrote:
> >> we should really
> >> get the ball rolling on our big patch backlog.
> >
> > Yes, please do. Softfreeze is not all that far away and I
> > would strongly prefer not to get an enormous sized pull
> > request at the last minute. The ideal pattern is that
> > code changes come in at a steady rate across the whole
> > of the 'open' part of the development cycle.
>
> Ya, sorry, we've been a bit out of it.  If I understand correctly, the
> soft
> freeze is the 30th?  If so it's really time to get started, and it looks
> like
> Michael is busy so I'll have to go figure this out.
>

Yes. I should think twice about the Signed-off-by: on my commits. I need to
run a regression on this out-of-order subset. I currently only run tests on
the top of the riscv-qemu tree in-order, and when I rebase against master.
If the commits need any significant effort to rebase because they are taken
in some random order then the testing will be invalidated. i.e. I haven't
checked the dependencies for these commits.

I am happy to review whoever posts the contents of the tree. I can test
apply the PRs against the riscv-qemu tree and if they give us lumps, we'll
reject, including my own changes (if rebased).

Alastair, I suggest you confer with Debian and Fedora folk. Don't break the
Linux distros... I'm petrified that we might break Debian.

Palmer, I disagree with idea, I would like to maintain the soft-fork until
we have the CI running our regression test suite (currently manual)

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.

Here is the pull queue. But I'm not ready to make a PR until we have the CI
running the regression. I certainly don't want rebases of random commits to
the riscv-qemu tree coming in when we pull.

- https://github.com/riscv/riscv-qemu/tree/qemu-for-upstream

That said, they have sign-off. There are plenty of other "RISC-V"
maintainers. Do what you think is wise.

Most important thing here is the Debian builders and other RISC-V virtual
machines in production. Having the Debian folk or some other helpful tester
running the entire tree. Pulling it in one go means we don't have a
bisection problem interspersed with a whole lot of other random patches.
You may not have all of the interrupt related changes that require
extensive parallel burn-in tests (GCC bootstrap). i.e. we do significantly
more than "make check" when we pull changes into our tree.

Thanks and Regards,
Michael.