> On Aug 31, 2020, at 2:55 PM, Nick Rosbrook <rosbro...@gmail.com> 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.dun...@citrix.com> wrote: >>> >>> >>> >>>> On Jul 21, 2020, at 1:35 AM, Nick Rosbrook <rosbro...@gmail.com> 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
