From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1DDI-00025W-H0 for qemu-devel@nongnu.org; Fri, 01 Feb 2013 04:47:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U1DDH-00053B-8V for qemu-devel@nongnu.org; Fri, 01 Feb 2013 04:47:16 -0500 Received: from cantor2.suse.de ([195.135.220.15]:48946 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1DDG-000537-VJ for qemu-devel@nongnu.org; Fri, 01 Feb 2013 04:47:15 -0500 Message-ID: <510B8F1A.6080404@suse.de> Date: Fri, 01 Feb 2013 10:47:06 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1359101996-11667-1-git-send-email-dantesu@gmail.com> <1359101996-11667-2-git-send-email-dantesu@gmail.com> <510AC221.4040903@samsung.com> <510B7D94.3020800@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 01/20] arm: add Faraday a36x SoC platform support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kuo-Jung Su Cc: Peter Maydell , i.mitsyanko@samsung.com, qemu-devel@nongnu.org, Blue Swirl , Paul Brook , Kuo-Jung Su , fred.konrad@greensocs.com =E5=97=A8 =E5=9C=8B=E6=A6=AE, 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. >=20 > However because most of my patches are new files, > should I send-out the patches with detail change log? >=20 > For example: >=20 > [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 appli= ed. * 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg