qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH v2 0/2] block: Gluster 6 compatibility


From: Niels de Vos
Subject: Re: [Qemu-block] [PATCH v2 0/2] block: Gluster 6 compatibility
Date: Tue, 12 Mar 2019 10:45:24 +0100
User-agent: Mutt/1.11.3 (2019-02-01)

On Mon, Mar 11, 2019 at 12:10:06PM +0100, Kevin Wolf wrote:
> Am 09.03.2019 um 10:40 hat Niels de Vos geschrieben:
> > On Fri, Mar 08, 2019 at 02:11:51PM +0100, Kevin Wolf wrote:
> > > Am 05.03.2019 um 16:46 hat Niels de Vos geschrieben:
> > > > Gluster 6 is currently available as release candidate. There have been a
> > > > few changes to libgfapi.so that need to be adapted by consuming projects
> > > > like QEMU. Fedora Rawhide already contains glusterfs-6.0-RC0, and this
> > > > prevents rebuilds of QEMU there (https://bugzilla.redhat.com/1684298).
> > > > 
> > > > The following two changes should be sufficient to consume Gluster 6 once
> > > > it is released. These have been tested on CentOS-7 with Gluster 5 and
> > > > Gluster 6 (minimal manual qemu-img tests only).
> > > > 
> > > > This v2 post contains changes suggested by Daniel P. Berrangé and Kevin
> > > > Wolf. Thanks!
> > > 
> > > Thanks, applied to the block branch.
> > 
> > Thanks! Stefano Garzarella gave a suggestion for further cleanup. I was
> > planning to address that (no #ifdef for function arguments) next week
> > when I'm back from a trip, Is that something you would also like to see,
> > or do you prefer the change to stay minimal/small as it is now? I'm
> > happy to send a followup if you agree that it is cleaner.
> 
> I don't mind either way.
> 
> I'm going to send a pull request tomorrow for soft freeze, but if you
> tell me that I should wait with this one, I can remove it from my queue
> for now. It's a bug fix, so we can still apply an updated version during
> the freeze.
> 
> A follow-up works for me, too, so whatever you prefer.

In that case, I prefer to keep the current patches as they are. If
further changes make the code much better readable/maintainable I would
have provided a new version. But at the moment, and after a little more
consideration, I do not think there is much benefit in the cleanup
Stefano suggested.

Thanks,
Niels



reply via email to

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