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

[Daniel P. Berrangé]

On Mon, Sep 30, 2019 at 05:17:32PM +0200, Andrea Bolognani wrote:
> 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.

No matter what we do, Realizing the advantage of familiarity with GLib
is not going to be something we win overnight. We have far too much
existing code for that to happen, so this familiarity is always something
that take time for us to achieve.

> 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.

I never suggested we want a conversion to run forever. It absolutely
must be time limited, it just doesn't all have to be done in one
giant big bang. Spreading it over several releases, with a clear
final deadline strikes a balance between getting it done and mitigating
pain for backporting.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|