qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support
Date: Mon, 7 Nov 2016 13:04:54 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

On Fri, Nov 04, 2016 at 10:51:43AM +0100, Igor Mammedov wrote:
> On Fri, 4 Nov 2016 09:15:48 +0000
> Stefan Hajnoczi <address@hidden> wrote:
> > On Fri, Nov 04, 2016 at 06:22:26AM +0200, Michael S. Tsirkin wrote:
> > > On Fri, Nov 04, 2016 at 06:01:54AM +0200, Michael S. Tsirkin wrote:  
> > > > On Fri, Nov 04, 2016 at 11:50:19AM +0800, Xiao Guangrong wrote:  
> > > > > On 11/04/2016 02:36 AM, Xiao Guangrong wrote:  
> > > > > > Hi Michael,
> > > > > > 
> > > > > > This patchset can replace the patches from [PULL 36/47] to [PULL 
> > > > > > 39/47]
> > > > > > in your pull request:
> > > > > > [PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available 
> > > > > > slots
> > > > > > [PULL 37/47] nvdimm acpi: introduce fit buffer
> > > > > > [PULL 38/47] nvdimm acpi: introduce _FIT
> > > > > > [PULL 39/47] pc: memhp: enable nvdimm device hotplug
> > > > > > 
> > > > > > Thanks for your patience also thank Igor and Stefan for their 
> > > > > > review.  
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > As the pull request has been upstream (Cool! :)), i will post
> > > > > diff changes based on that.
> > > > > 
> > > > > Thanks!  
> > > > 
> > > > Igor prefers seeing revert+patches, I prefer seeing a diff.
> > > > Can you send both? A global diff would be ok for me
> > > > as it's small and easy enough to generate.  
> > > 
> > > Stefan, I wonder what's easier for you to review?  
> > 
> > Since it has been merged into qemu.git/master I'd now like to see
> > follow-up patches.  Not a global diff but real individual changes on top
> > of qemu.git/master.  These fixes can be merged during softfreeze.
> 
> Incremental followup patches will make review a bit harder as
> they should remove code that's shouldn't have been there is
> the first place and would be fixing existing mess.
> 
> But since majority prefers incremental followup patches lets do
> it this way.

For the record I would have preferred to get the patch series right
before merging it.

I guess that Michael favors development velocity and there are arguments
why merging code before it's perfect can help it mature more quickly.

If we merge things before they are ready then it's important that
incomplete features are marked experimental/unstable.  But in this case
I guess the strategy will be to merge the fixes during soft-freeze
(before Nov 15th) so that QEMU 2.8 ships the finalized code.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]