Date:   Wed, 12 Jul 2017 09:58:01 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Olof Johansson <olof@...om.net>,
        Andrew Morton <akpm@...ux-foundation.org>, albert@...ive.com,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <mmarek@...e.com>,
        Will Deacon <will.deacon@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Ingo Molnar <mingo@...hat.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        gregkh <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        David Miller <davem@...emloft.net>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Frédéric Weisbecker <fweisbec@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Doug Ledford <dledford@...hat.com>,
        Bart Van Assche <bart.vanassche@...disk.com>,
        sstabellini@...nel.org, Daniel Vetter <daniel.vetter@...ll.ch>,
        Michael Ellerman <mpe@...erman.id.au>,
        Mark Salter <msalter@...hat.com>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>,
        James Hogan <james.hogan@...tec.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        patches@...ups.riscv.org
Subject: Re: RISC-V Linux Port v6

On Wed, Jul 12, 2017 at 3:31 AM, Palmer Dabbelt <palmer@...belt.com> wrote:
> While it's only been a day since the last patch set (which might be a bit
> fast), I've generally been spinning new patch sets whenever I get through my
> inbox.  For my other patch sets I've managed to get buried in a week's worth of
> email in a few hours, but for this one it appears there's been significantly
> less feedback so I've managed to get through everything.  I'm hoping that's a
> good sign: either I've started to figure out what I'm doing or the code has
> gotten better -- hopefully it doesn't mean everyone else has given up :).

I don't seem have received the last few versions, but I did get this one,
good to see the progress!

A few general notes for the next version:

- please always include the patch version in the subject for each
  patch, as 'git format-patch -v 7' will do.

- In the introductory mail, list the entire history since v1 if you can
  reconstruct it. I'm pretty lost now keeping track of earlier versions
  and what has changed compared to this one, so I'd have to start
  reviewing from scratch.

> As it's been only a day, the changes are pretty minimal:
>
>  * The patch set is now based on linux-next/master, which I believe is a better
>    base now that we're getting closer to upstream.

It's not entirely clear though. Until the end of the merge window, this is fine,
as stuff in linux-next today is likely to end up in 4.13-rc1 on Sunday.
However, once -rc1 is out, you should base your patches on that to
get a bisectable patch series once it is merged. If there are conflicts
or dependencies on other trees that get scheduled for 4.14, we have
to see how to resolve them one at a time.

> At this point I'm not really sure how to proceed: reviews have calmed down
> quite a bit over the last two weeks, but I'm not familiar with the Linux
> development process enough to know how to get closer to upstream.  Is this
> ready for inclusion into another tree?  If so, is linux-next the right tree to
> work off of?

Without having looked at the current state of the patch series, I would
guess that next week is a good time to ask for inclusion *in* linux-next,
while continuing the review.

This should exclude the device driver patches (irqchip, clocksource,
tty) that get merged by other maintainers as they see
fit, but I would include the lib/ patch in your series, which is a
build-time requirement.

For the pci patch, ask Bjorn if he has a preference whether he wants
to merge the patch or have you put it into your tree with his
'Acked-by' tag.

Are there any remaining review comments that you got for the
arch/riscv/* patches? If not, I'll try to do another full review soon
and provide my own Ack for any patch that I feel qualified as
a reviewer. The patches that got lots of review comments from
others should ideally also get an Ack from those reviewers.

Once you you have enough Acks, you can then change your
operational mode from modifying the commits in place, to
only adding patches on top for addressing further changes.

In the long run, the way this usually works is that you have
one stable tree that only gets patches on top, while new
features are developed on separate branches and then
applied or merged to that branch once they are done.

You may also want to have separate 'fixes' and 'next' branches
that are both public. The 'fixes' branch is what you send to
Linus between the merge windows when you find bugs,
while the 'next' branch is part of linux-next and it gets
tagged for the pull request that you send at the beginning
of each merge window.

> Of course, if anyone has outstanding code reviews then feel free to submit them
> either to this patch set or a previous one (v5 is essentially the same, and v4
> is mostly some small SMP fixes).  I don't want to rush anyone by re-submitting
> so quickly, it's just that my usual protocol has been sped up.
>
> As usual, the patch set has been posted to our Git Hub page
>
>   https://github.com/riscv/riscv-linux/tree/riscv-for-submission-v6

There are a couple of downsides to hosting the git tree on github,
so as you get nearer to inclusion, you should decide whether to
have your own git server on riscv.org or sifive.com, or to get an
account on kernel.org.

You should also make sure you get your gpg key signed by other
kernel maintainers so you can properly sign git tags for pull requests.
The signatures are a requirement for an account on kernel.org but
are generally a good idea even when you have the tree on github
or your own site. https://www.kernel.org/doc/ksmap/ shows some
people that are closeby.

       Arnd

Powered by blists - more mailing lists