From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Salil Mehta" <salil.mehta@huawei.com>,
"Harsh Prateek Bora" <harshpb@linux.ibm.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "danielhb413@gmail.com" <danielhb413@gmail.com>,
"vaibhav@linux.ibm.com" <vaibhav@linux.ibm.com>,
"sbhat@linux.ibm.com" <sbhat@linux.ibm.com>
Subject: Re: [PATCH v2 1/4] accel/kvm: Extract common KVM vCPU {creation, parking} code
Date: Fri, 17 May 2024 13:44:20 +1000 [thread overview]
Message-ID: <D1BLZ35ZE9EI.18TYUB70KCCY7@gmail.com> (raw)
In-Reply-To: <7a5608c768254869a4a6b68d719c24f1@huawei.com>
On Thu May 16, 2024 at 11:35 PM AEST, Salil Mehta wrote:
>
> > From: Harsh Prateek Bora <harshpb@linux.ibm.com>
> > Sent: Thursday, May 16, 2024 2:07 PM
> >
> > Hi Salil,
> >
> > On 5/16/24 17:42, Salil Mehta wrote:
> > > Hi Harsh,
> > >
> > >> From: Harsh Prateek Bora <harshpb@linux.ibm.com>
> > >> Sent: Thursday, May 16, 2024 11:15 AM
> > >>
> > >> Hi Salil,
> > >>
> > >> Thanks for your email.
> > >> Your patch 1/8 is included here based on review comments on my previous
> > >> patch from one of the maintainers in the community and therefore I had
> > >> kept you in CC to be aware of the desire of having this independent patch to
> > >> get merged earlier even if your other patches in the series may go through
> > >> further reviews.
> > >
> > > I really don’t know which discussion are you pointing at? Please
> > > understand you are fixing a bug and we are pushing a feature which has got large series.
> > > It will break the patch-set which is about t be merged.
> > >
> > > There will be significant overhead of testing on us for the work we
> > > have been carrying forward for large time. This will be disruptive. Please dont!
> > >
> >
> > I was referring to the review discussion on my prev patch here:
> > https://lore.kernel.org/qemu-devel/D191D2JFAR7L.2EH4S445M4TGK@gmail.com/
>
>
> Sure, I'm, not sure what this means.
>
>
> > Although your patch was included with this series only to facilitate review of
> > the additional patches depending on just one of your patch.
>
>
> Generally you rebase your patch-set over the other and clearly state on the cover
> letter that this patch-set is dependent upon such and such patch-set. Just imagine
> if everyone starts to unilaterally pick up patches from each other's patch-set it will
> create a chaos not only for the feature owners but also for the maintainers.
>
>
> >
> > I am not sure what is appearing disruptive here. It is a common practive in
> > the community that maintainer(s) can pick individual patches from the
> > series if it has been vetted by siginificant number of reviewers.
>
>
> Don’t you think this patch-set is asking for acceptance for a patch already
> part of another patch-set which is about to be accepted and is a bigger feature?
> Will it cause maintenance overhead at the last moment? Yes, of course!
>
>
> > However, in this case, since you have mentioned to post next version soon,
> > you need not worry about it as that would be the preferred version for both
> > of the series.
>
>
> Yes, but please understand we are working for the benefit of overall community.
> Please cooperate here.
There might be a misunderstanding, Harsh just said there had not been
much progress on your series for a while and he wasn't sure what the
status was. I mentioned that we *could* take your patch 1 (with your
blessing) if there was a hold up with the rest of the series. He was
going to check in with you to see how it was going.
This patch 1 was not intended to be merged as is without syncing up with
you first, but it's understandable you were concerned because that was
probably not communicated with you clearly.
I appreciate you bringing up your concerns, we'll try to do better.
Thanks,
Nick
next prev parent reply other threads:[~2024-05-17 3:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 5:32 [PATCH v2 0/4] target/ppc: vcpu hotplug failure handling fixes Harsh Prateek Bora
2024-05-16 5:32 ` [PATCH v2 1/4] accel/kvm: Extract common KVM vCPU {creation, parking} code Harsh Prateek Bora
2024-05-16 8:30 ` Salil Mehta via
2024-05-16 10:15 ` Harsh Prateek Bora
2024-05-16 12:12 ` Salil Mehta via
2024-05-16 13:06 ` Harsh Prateek Bora
2024-05-16 13:35 ` Salil Mehta via
[not found] ` <5bd52d8f5aaa49d6bc0ae419bb16c27c@huawei.com>
2024-05-16 14:19 ` Salil Mehta
2024-05-16 14:53 ` Harsh Prateek Bora
2024-05-17 3:44 ` Nicholas Piggin [this message]
2024-05-17 10:13 ` Salil Mehta via
2024-05-16 5:32 ` [PATCH v2 2/4] accel/kvm: Introduce kvm_create_and_park_vcpu() helper Harsh Prateek Bora
2024-05-16 5:32 ` [PATCH v2 3/4] cpu-common.c: export cpu_get_free_index to be reused later Harsh Prateek Bora
2024-05-16 5:32 ` [PATCH v2 4/4] target/ppc: handle vcpu hotplug failure gracefully Harsh Prateek Bora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D1BLZ35ZE9EI.18TYUB70KCCY7@gmail.com \
--to=npiggin@gmail.com \
--cc=danielhb413@gmail.com \
--cc=harshpb@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=salil.mehta@huawei.com \
--cc=sbhat@linux.ibm.com \
--cc=vaibhav@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.