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

[Laine Stump]

On 9/30/19 1:35 PM, Andrea Bolognani wrote:
> On Mon, 2019-09-30 at 13:13 -0400, Laine Stump wrote:
>> On 9/30/19 10:05 AM, 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.
>> Don't forget that make syntax-check doesn't work properly for many
>> downstream maintenance branches that would be backported to (it has to
>> be disabled due to copyright date checks failing, or something like
>> that).
> That's a problem for downstream to solve. By the same token, all
> the existing syntax-check rules are pointless because they can't be
> guaranteed to hold for downstream branches.


Yeah, I'm just bitter that make syntax-check doesn't work downstream, 
and can't let a mention of the two in the same context go by without 
making a whining comment.


>> In order to allay Andrea's fears of new usage of VIR_AUTO* that just
>> draws out the conversion, maybe we could (temporarily, until the
>> conversion is complete) put a commit hook in place to disallow new use
>> of VIR_AUTO ? Or just, you know, pay attention in reviews (but of course
>> part of the point of all of this is to eliminate the potential for human
>> error, by depending less on humans paying attention, so... :-P)
> Writing a check that compares the situation before a commit and
> after it is not as easy as a point-in-time check.


Not all that bad though - just examine the lines that start with +


>   Instead of spending
> a non-trival amount of time implementing something like that, I'd
> rather spend my time dealing with the fallout of a one-time
> conversion.


Without seeing concrete examples of what actually is "dealing with the 
fallout" in both cases, I don't want to speculate too much on which 
would cause more difficulty. I would say that even if we do the 
conversion all at once, it should be in multiple patches so that if 
there is some regression caused by the conversion, a git bisect will 
lead to a multi-hundred line commit instead of a multi-thousand line commit.


>> (BTW, I'm not firmly in *either* camp, although I may lean a bit more
>> towards a gradual change (but with a *very* steep slope to minimize the
>> period of confusion)
> That's just a big-bang conversion with extra steps!


Well, after all *anything* we each do before meeting a sad and lonely 
demise is really just a part of Heat Death of the Universe with extra 
steps. You need to subdivide *somewhere*.