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

Peter Krempa pkrempa at redhat.com
Mon Sep 30 15:24:00 UTC 2019


On Mon, Sep 30, 2019 at 16:10:11 +0100, Daniel Berrange wrote:
> 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:

[...]

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

I doubt that there will be any motivation to start a incremental
coversion. While when adding VIR_AUTOFREE and coverting to it there was
a clear benefit of simplification in doing so, converting from
VIR_AUTOFREE to g_autofree has exactly 0 benefit.

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

How is this not a big-bang conversion?




More information about the libvir-list mailing list