Re: [libvirt] [PATCH 06/11] util: use glib base64 encoding/decoding APIs
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*.