Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH v7 0/4] ARM: SoC: add a new platform, UniPhier (arch/arm/mach-uniphier) | Date | Wed, 24 Aug 2016 17:31:19 +0200 |
| |
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
| |