[libvirt] [PATCH 06/11] util: use glib base64 encoding/decoding APIs

Andrea Bolognani abologna at redhat.com
Mon Sep 30 15:17:32 UTC 2019


On Mon, 2019-09-30 at 15:53 +0100, Daniel P. Berrangé wrote:
> On Mon, Sep 30, 2019 at 04:05:57PM +0200, Andrea Bolognani wrote:
> > I see your point about backports being more painful when you have
> > a bunch of unrelated changes mixed in, but I would still prefer if
> > we converted everything at once and at the same time introduced a
> > suitable syntax-check rule preventing more instances of whatever
> > function we just removed all callers of from creeping back in, or
> > actually just dropping the function altogether.
> > 
> > Doing the conversion incrementally will IMHO result in dragging it
> > for much longer, causing more pain in the long run than ripping the
> > bandaid would.
> 
> There's really not any significant real world pain from mixing the
> two styles. It is visually distasteful but doesn't cause any functional
> problems at runtime, nor complexity for maintainers. A large conversion
> over the whole codebase does cause very significant pain in conflicts
> for anyone cherry picking patches. That is just not a net win overall.
> I'll take visually mixed styles any day over creating patch conflicts
> in backports.

If we allow both at the same time, then we'll keep using both going
forward because there's no incentive *not* to mix the two styles;
one of the stated advantages of adopting GLib, making the libvirt
code base more approachable to people familiar with QEMU and other
GLib-using projects, will then not be realized.

Both the conversion from one style to the other and, consequently,
addressing any conflict resulting from it, can be tackled in a
purely mechanical fashion: a bit annoying, sure, but hardly worth
keeping the conversion ongoing forever for in my opinion.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list