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

[Kuo-Jung Su]

2013/2/1 Andreas Färber <address@hidden>:
> 嗨 國榮,
>
> 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. :)
>

Thanks. It's so kind of you for helping me building up
the common sense about patch process.

>> 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.

Thanks, now I understand what am I supposed to do.

> * 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.

Thanks, I'm now re-formating the patch set.

> * Maybe you can order EHCI last due to the refactoring work involved?

I plan to again work on FUSBH200 - EHCI later when the A36x patch set
have been applied.

>
> 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.
>

'git rebase' is simply too complicated to me.
I'm now using 'git cherry-pick' and 'git branch' to re-format the patches.

> 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



--
Best wishes,
Kuo-Jung Su