[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches
From: |
Michael Clark |
Subject: |
Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches |
Date: |
Fri, 12 Oct 2018 09:52:07 +1300 |
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.
- Re: [Qemu-devel] [PATCH v1 4/5] RISC-V: Add missing free for plic_hart_config, (continued)
- [Qemu-devel] [PATCH v1 5/5] RISC-V: Don't add NULL bootargs to device-tree, Alistair Francis, 2018/10/08
- Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches, Palmer Dabbelt, 2018/10/10
- Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches, Peter Maydell, 2018/10/10
- Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches,
Michael Clark <=
- Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches, Peter Maydell, 2018/10/12
- Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches, Palmer Dabbelt, 2018/10/15
- Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches, Peter Maydell, 2018/10/16
- Re: [Qemu-devel] [PATCH v1 0/5] Misc RISC-V patches, Palmer Dabbelt, 2018/10/16