Re: [Qemu-devel] [PATCH v2 01/20] arm: add Faraday a36x SoC platform support

[Andreas Färber]

嗨 國榮,

Am 01.02.2013 09:57, schrieb Kuo-Jung Su:
> Thanks for the information, and sorry for the mess I've done.

You don't need to apologize for every review comment you get. It's
meant for improvements of results, not personal. :)

> I'll one-by-one re-send all the patches.
> 
> However because most of my patches are new files,
> should I send-out the patches with detail change log?
> 
> For example:
> 
> [PATCH] dumb timer
> ... [PATCH v2 0/2] dumb timer (Cover letter)
>     [PATCH v2 1/2] dumb timer (The one in Patch V1)
>     [PATCH v2 2/2] dumb timer: coding style update (Change log for V2)
> ...... [PATCH v3 0/2] dumb timer (Cover letter)
>        [PATCH v3 1/2] dumb timer (The merged file in Patch V1 & v2)
>        [PATCH v3 2/2] dumb timer: bug fix (Change log for V3)

No, no, no. What you should do is just something like:

[PATCH v3 0/x] Add Faraday A36x SoC platform support
    [PATCH v3 1/x] arm: Add Faraday A360 and A369 machines
    [PATCH v3 2/x] faraday_a36x: Add FT... timer
    ...

* v3 cover letter contains a change log going back to v1.
* v3 is not a reply to v2 (no --in-reply-to). This aids a threaded mail
display for reviewing and avoids an old version getting reviewed or applied.
* 1+/x are replies to 0/x (usually automatically by git-send-email).
That helps keep the patches together and in the right order.
* Bug fixes of your own code do not go separate (only if you were fixing
existing code from qemu.git). There's no need to introduce bugs and then
to fix them.
* Adding a stub machine in 1/x has the advantage that the patch is much
smaller and easier to review than first adding all devices and then
adding a machine that uses all of them. And each device being added in
(1+n)/x can be tested (system not fully working of course). I.e., the
machine will grow in functionality patch by patch.
* Maybe you can order EHCI last due to the refactoring work involved?

To aid with the requested reordering and squashing of bug fixes into
patches, `git rebase -i` and `git checkout -p` may be of help to you.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg