Hi All, On Thu, Oct 11, 2018 at 7:22 AM Palmer Dabbelt <pal...@sifive.com> wrote:
> On Wed, 10 Oct 2018 11:10:07 PDT (-0700), peter.mayd...@linaro.org wrote: > > On 10 October 2018 at 18:49, Palmer Dabbelt <pal...@sifive.com> 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.
