2013/2/1 Andreas Färber <afaer...@suse.de>: > 嗨 國榮, > > 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
