Re: Golang design session follow-up

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Aug 31, 2020, at 2:55 PM, Nick Rosbrook <rosbrookn@xxxxxxxxx> wrote:
> 
> On Fri, Aug 28, 2020 at 07:05:08PM +0000, George Dunlap wrote:
>> 
>> 
>>> On Aug 28, 2020, at 4:57 PM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>>> 
>>> 
>>> 
>>>> On Jul 21, 2020, at 1:35 AM, Nick Rosbrook <rosbrookn@xxxxxxxxx> wrote:
>>>> 
>>>> # Long-term home of the package
>>>> 
>>>>  Ian: Autogenerated stuff is becoming more annoying.
>>>> 
>>>>  Delete all the libxl auto-generated stuff from staging & master, and have 
>>>> "output branch".
>>>> 
>>>>  The reason we have these in-tree is that otherwise you can't build *from 
>>>> git* if you don't 
>>>>  have new enough versions of the right tools.
>>>> 
>>>>  Distribution: Make a repo on xenbits!
>>> 
>>> So thinking about this: 
>>> 
>>> The first plan I had was to have a script in tools/golang/xenlight (and/or 
>>> the Makefile), which would be handed a directory, and would then:
>>> 
>>> 1. Sync static files from tools/golang/xenlight into that directory
>>> 
>>> 2. Run gengotypes.py, having the resulting generated files put into that 
>>> directory
>>> 
>>> 3. Run `git diff` in the target directory; if there are any changes, then 
>>> automatically run `git commit` to check in the changes.
>>> 
>>> That way you could just set up a cron job to sync things over on a regular 
>>> basis.
>>> 
>>> Thinking about GPL considerations, however, you’d also want to include 
>>> libxl_types.idl and idl.py.  And then of course, you should also include a 
>>> way to build the generated code from those two.
>>> 
>>> At which point… would it make sense to just move the package out to its 
>>> separate repo entirely?  I.e., have actual development happen in the repo 
>>> which ends up being cloned in the end?
>>> 
>>> Obviously there are nice things about having the code in the same repo; but 
>>> there’s also something satisfying about being a full downstream.
>>> 
>>> I was actually thinking it might make sense to put the repo at 
>>> https://gitlab.com/xen-project/go-xenlight , to try out that as a 
>>> development model.
> Would that mean completely moving off of xen-devel for development? I can't 
> think of a huge reason why we wouldn't be able to do this if we wanted.

I mean obviously the changes to libxl_types.idl and idl.py would have to happen 
on xen-devel; but yeah, changes to the external repo would happen within gitlab.

>> 
>> I’ve put a sort of draft module up at https://gitlab.com/martyros/go-xen ; 
>> you can test it by adding the "gitlab.com/xen-project/go-xen/xenlight” 
>> package, but adding the following line to the go.mod of the test program:
> I have a couple of patches I was going to send out on xen-devel today. I 
> could PR them to this repo instead (or in addition) if you want to try out 
> the gitlab workflow. 

Yeah, we could give that a try.

 -George