Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile

From: George Dunlap <George.Dunlap@citrix.com>
To: Nick Rosbrook <rosbrookn@gmail.com>
Cc: Nick Rosbrook <rosbrookn@ainfosec.com>,
	xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile
Date: Mon, 8 Jun 2020 09:54:13 +0000	[thread overview]
Message-ID: <DCC151DE-9CCD-43DA-97BA-F087EB4E80F3@citrix.com> (raw)
In-Reply-To: <20200604182938.GA10975@six>

> On Jun 4, 2020, at 7:29 PM, Nick Rosbrook <rosbrookn@gmail.com> wrote:
> 
>> The simplest short-term way to fix this would be to remove the `go fmt` call from `gengotypes.py`.  It’s actually relatively unusual for generated code to look pretty (or even be looked at).  We could also consider adding in some “manual” formatting in gengotypes.py, like indentation, so that it doesn’t look too terrible.
>> 
>> Nick, do you have time to work on a patch like that?
> 
> Yes, I have time to work on a quick patch for this. I'll see what it
> would take to add a bit of basic manual formatting, but of course the
> original purpose of using gofmt was to avoid re-creating formatting
> logic. I'll likely just remove the call to go fmt.
> 
> Out of curiosity, would it be totally out of the question to require
> having gofmt installed (not for 4.14, but in the future)? I ask because
> I haven't seen it discussed one way or the other.

I think I’d like to try to avoid it, unless / until we have a “core component” written in golang.  For one, if we added it as a core dependency, we’d need to be  backwards compatible to the oldest version of golang of distros on which we want to build; that would include  Debian oldstable, Ubuntu LTS, probably CentOS 7 at least, possibly CentOS 6, and so on.  If any of those didn’t have golang available, then we’d basically have to decide between dropping support for those distros, and making golang optional.

I don’t at the moment have a good feel for what other people in the community feel about this, but generally speaking being fanatically backwards compatible is an investment in the long-term ecosystem; keeping Xen *as a whole* building on older distros is an example of that.  (FWIW I don’t think we have an official rubric, but my starting point is that we should try to build on all still-supported major distros; that would include CentOS 6 until Q4 of 2020, if my quick Google search is correct.)

One advantage of making golang optional is that we don’t have to be quite so backwards compatible — up until we declare the feature “fully supported”, we can move the minimum required version forward at will if we want to rely on new features.

 -George