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

[Daniel P. Berrangé]

On Mon, Sep 30, 2019 at 05:03:47PM +0200, Peter Krempa wrote:
> On Mon, Sep 30, 2019 at 15:53:35 +0100, Daniel Berrange wrote:
> > On Mon, Sep 30, 2019 at 04:05:57PM +0200, Andrea Bolognani wrote:
> > > On Mon, 2019-09-30 at 13:41 +0100, Daniel P. Berrangé wrote:
> > > > On Mon, Sep 30, 2019 at 02:18:17PM +0200, Andrea Bolognani wrote:
> > > > > On Mon, 2019-09-30 at 13:56 +0200, Pavel Hrdina wrote:
> 
> [...]
> 
> > > > Incrementally converting VIR_ALLOC + VIR_AUTOFREE at the same
> > > > time, makes more sense stylewise, as then within the scope of a
> > > > single method we'd be consistent.
> > > 
> > > 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.
> 
> I don't see how. If the end-goal is to convert everything to the new
> form you will get into potential pain/conflicts sooner or later anyways.

If we incrementally convert methods, then when backporting a patch
related to that method, we have good chance of being able to cherry-pick
the small conversion patch. If we bulk convert entire file at a time,
across the whole codebase, attempting to cherry-pick the conversion patches
will have much higher conflict liklihood.

> Or the other option is to leave it as a half-done lingering refactor and
> that doesn't help either.

It don't be in a half-done state forever. We can let things be converted
incrementally over the next 3-6 months. At the end of say 6 months if
anything is left we bulk convert it them. That gets the benefits opf
incremental work without downside of stuff remaining unconverted forever.

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