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

[Nick Rosbrook <rosbrookn@xxxxxxxxx>]

On Tue, Aug 25, 2020 at 10:37:09AM +0000, George Dunlap wrote:
> 
> 
> > On Aug 25, 2020, at 7:47 AM, Jan Beulich <JBeulich@xxxxxxxx> 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.

Yeah, that's probably best. I for one do not have any immediate plans
for working on option C.

Jan - I apologize for the confusion, I certainly did not mean to be
unfriendly or hold up your work.

-NR