Re: [PATCH v7 0/4] ARM: SoC: add a new platform, UniPhier (arch/arm/mach-uniphier)

[Arnd Bergmann <arnd@arndb.de>]

On Thursday, August 18, 2016 3:46:17 AM CEST Masahiro Yamada wrote:
> 2016-01-18 22:49 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> > On Monday 18 January 2016 19:54:08 Masahiro Yamada wrote:
> 
> I collected a couple of GPG signatures and
> finally, I managed to host my git tree in the kernel.org site.
> 
> From this development cycle (for v4.9-rc1),
> I'd like to send a few pull requests instead of
> asking you to pick up separate patches.

Ok, very good.

> If it is OK with you,
> could you apply the following patch?
> https://patchwork.kernel.org/patch/9286311/
> 
> If it is applied, I will regard it as your acknowledgment
> for my pull requests.

No need for that, I've added the patch to my todo folder and
will apply it along with the next batch of merges, but feel
free to send any pull requests you have right away.

> Could you teach me some good practice about PRs?
>
> 
> >> > When you do pull requests, please split them up according to larger
> >> > topics, e.g. send dts changes separately from code changes, and
> >> > separate bug fixes, cleanups and new feature support.
> 
> I will make sure to do this.
> Mostly, I will send pull requests for device tree updates for UniPhier
> SoC family.
> 
> Also, I will split them into ARM32 DTS and ARM64 DTS as others do.

Ok, sounds good. I think the easiest way is to just let you know
when I want the pull requests to be done any differently.

> What else?
> 
>  - On which tag should I base my PRs?   -rc1 or -rc2?
>    Or do you want it based on some branch?

They should always be sent on an -rc release that you are testing
on, preferably an early one like -rc1 or -rc2. The important
part here is to avoid "back-merges" of upstream contents into
our next/* branches, as that tends to mess up the git history.

We usually base our branches on -rc3, which means that you can
send your contents based on -rc1, -rc2 or -rc3, but not based on
-rc4.

It sometimes happens that you require a bugfix as the base, and
that may have been merged into -rc4. We can make exceptions
for that, or alternatively you can base your own changes on
top of that bugfix, e.g. if the branch that contained the fix
was based on -rc2 and merged into -rc4.

>  - Do you require a tag with GPG signature for accepting a pull-request?
>     (Greg KH and I signed GPG keys with each other.
>      Perhaps, are we connected with web of trust?)

Yes, the tag should have both a valid signature and a meaningful
tag description that gets used as the commit description for
the merge commit when we merge it.

The best commit logs identify all the important changes and
give an overview of what is in the branch. However, there
is no need to list every single commit that went into the
branch, often enough a lot of the patches in one branch
are simple cleanups and can be summarized with a few words
(and readers can refer to the shortlog for more details).

	Arnd