> I'm afraid this isn't the way a v2 patchseries should be structured. > The idea is that a v2 series should be complete in itself, not based on whatever v1 > was. So when you make the changes requested in review of v1, you update the > commits in your local git branch, and then you send out the patches as the v2. v2 > should apply cleanly on to master, and all the patches in it should be logically > separated out changes (with no "patch 1 makes a change and then patch 2 > changes the code that was added in patch 1" effects). Thank you for comments. We apologize for the inconvenience caused by our lack of understanding. I understood your point. Just to confirm, should I update to v3 and resubmit it as a patch series based on the points you mentioned? Best regards. > -----Original Message----- > From: Peter Maydell <peter.maydell@linaro.org> > Sent: Friday, July 30, 2021 7:39 PM > To: Ishii, Shuuichirou/石井 周一郎 <ishii.shuuichir@fujitsu.com> > Cc: qemu-arm <qemu-arm@nongnu.org>; QEMU Developers > <qemu-devel@nongnu.org> > Subject: Re: [PATCH v2 0/3] Add support for Fujitsu A64FX processor > > On Fri, 30 Jul 2021 at 04:08, Shuuichirou Ishii <ishii.shuuichir@fujitsu.com> > wrote: > > > > This is the v2 patch series. > > > > v2: > > No features have been added or removed from the v1 patch series. > > Removal of unused definitions that were added in excess, and > > consolidation of patches for the purpose of functional consistency. > > > > For patch 1, ARM_FEATURE_A64FX is not used in the v1 patch series, so > > it was deleted this time, and will be added again when it is used. > > > > For patch 2, since the a64fx_cp_reginfo structure is not used in the > > v1 patch series, I deleted the empty definition and added the TODO in > > the aarch64_a64fx_initfn function. Also fixed the appearance, and > > cleaned up and removed some things for patch consistency. > > > > For patch 3, a64fx was added to docs/system/arm/virt.rst and > > hw/arm/virt.c respectively, as a modification to the patch consistency > > cleanup done in patch 2. > > I'm afraid this isn't the way a v2 patchseries should be structured. > The idea is that a v2 series should be complete in itself, not based on whatever v1 > was. So when you make the changes requested in review of v1, you update the > commits in your local git branch, and then you send out the patches as the v2. v2 > should apply cleanly on to master, and all the patches in it should be logically > separated out changes (with no "patch 1 makes a change and then patch 2 > changes the code that was added in patch 1" effects). > > thanks > -- PMM
On Tue, 3 Aug 2021 at 01:37, ishii.shuuichir@fujitsu.com <ishii.shuuichir@fujitsu.com> wrote: > > > I'm afraid this isn't the way a v2 patchseries should be structured. > > The idea is that a v2 series should be complete in itself, not based on whatever v1 > > was. So when you make the changes requested in review of v1, you update the > > commits in your local git branch, and then you send out the patches as the v2. v2 > > should apply cleanly on to master, and all the patches in it should be logically > > separated out changes (with no "patch 1 makes a change and then patch 2 > > changes the code that was added in patch 1" effects). > > Thank you for comments. > We apologize for the inconvenience caused by our lack of understanding. > I understood your point. > > Just to confirm, > should I update to v3 and resubmit it as a patch series based on the points you mentioned? Yes, please. thanks -- PMM
© 2016 - 2024 Red Hat, Inc.