Re: [PATCH v2 1/4] accel/kvm: Extract common KVM vCPU {creation, parking} code

[Nicholas Piggin]

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:
> >  D191D2JFAR7L.2EH4S445M4TGK@gmail.com/">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