Re: [PATCH] libxl: avoid golang building without CONFIG_GOLANG=y

[George Dunlap <George.Dunlap@citrix.com>]

> On Aug 25, 2020, at 7:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
> On 24.08.2020 16:58, Nick Rosbrook wrote:
>> My understanding was that you were going to use move-if-changed to fix
>> this for now (it seemed everyone agreed this was the quickest short-term fix).
> 
> A technical and a non-technical remark:
> 
> Thinking about this some more, I'm no longer convinced the
> move-if-changed approach is appropriate here. It is typically
> used to avoid updating files with a large set of dependents
> (all of which would need re-building if the file in question
> changed, even if merely in its time stamp), and where the
> cost of re-generating (and comparing) is relatively low.
> While I can't really assess the cost part here (I know too
> little of Python to be able to compare its use with e.g. a
> shell script), I don't think the "large set of dependencies"
> aspect applies here at all.
> 
> On the non-technical side I have to admit that I find it,
> well, unfriendly to have a person not only run into and
> investigate a (recent) regression, but also make multiple
> attempts at fixing (or at least working around) it. I'd
> rather view this as preferably the responsibility of the
> person having introduced an issue. In the case at hand it is
> quite clear that I wasn't even remotely aware of the
> requirements, and hence determination and testing of a more
> adequate solution would far better be done by someone
> familiar with all the influencing factors. (Things might
> yet be different if an issue is difficult to reproduce, but
> I don't see that being the case here.)

Yes, this has been sub-optimal for you to have your functionality broken for several weeks.

As an explanation, there are a combination of things. You proposed A (remove the dependency), Ian proposed B (use move-if-changed), but we’re hoping to do C (have an external tree) before the next release.  I haven’t had the time to look into either B or C (nor, unfortunately, to review Nick’s submissions to other parts of the code — sorry Nick!); but I’ve still been reluctant to go for A.

I think basically, unless someone is ready to tackle B or C immediately, we should just check in Jan’s fix (or probably better, just revert the patch that introduced the dependency).  It will be annoying to have to potentially fix up the generated golang bindings, but that puts the incentives in the right place.

 -George