qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PULL 0/7] Block patches for 4.1.0-rc4


From: Peter Maydell
Subject: Re: [Qemu-block] [Qemu-devel] [PULL 0/7] Block patches for 4.1.0-rc4
Date: Tue, 6 Aug 2019 12:53:42 +0100

On Tue, 6 Aug 2019 at 12:12, Max Reitz <address@hidden> wrote:
>
> On 06.08.19 12:12, Peter Maydell wrote:
> > On Mon, 5 Aug 2019 at 18:01, Max Reitz <address@hidden> wrote:
> >>
> >> On 05.08.19 18:59, Vladimir Sementsov-Ogievskiy wrote:
> >>> 05.08.2019 19:37, Max Reitz wrote:
> >>>> The following changes since commit 
> >>>> 9bb68d34dda9be60335e73e65c8fb61bca035362:
> >>>>
> >>>>    Merge remote-tracking branch 
> >>>> 'remotes/philmd-gitlab/tags/edk2-next-20190803' into staging (2019-08-05 
> >>>> 11:05:36 +0100)
> >>>>
> >>>> are available in the Git repository at:
> >>>>
> >>>>    https://github.com/XanClic/qemu.git tags/pull-block-2019-08-05
> >>>>
> >>>> for you to fetch changes up to 07b0851c592efe188a87259adbda26a63c61dc92:
> >>>>
> >>>>    block/backup: disable copy_range for compressed backup (2019-08-05 
> >>>> 18:05:05 +0200)
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Block patches for 4.1.0-rc4:
> >>>> - Fix the backup block job when using copy offloading
> >>>> - Fix the mirror block job when using the write-blocking copy mode
> >>>> - Fix incremental backups after the image has been grown with the
> >>>>    respective bitmap attached to it
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Max Reitz (5):
> >>>>    backup: Copy only dirty areas
> >>>>    iotests: Test backup job with two guest writes
> >>>>    iotests: Test incremental backup after truncation
> >>>>    mirror: Only mirror granularity-aligned chunks
> >>>>    iotests: Test unaligned blocking mirror write
> >>>>
> >>>> Vladimir Sementsov-Ogievskiy (2):
> >>>>    util/hbitmap: update orig_size on truncate
> >>>>    block/backup: disable copy_range for compressed backup
> >>>>
> >>>
> >>> As I understand, this all should go to stable too? CC it.
> >> Ah, yes.  Thanks.
> >
> > Are you planning to send a respin with the CC:stable tags?
> > (I did a test merge of this version which all passed OK.)
>
> I thought Vladimir just meant to physically CC qemu-stable on the series
> (which he did).  Should I respin with the tags?

If you could do a quick respin that's probably most reliable --
I'm not sure exactly how the qemu-stable process works, though.

thanks
-- PMM



reply via email to

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