On 4/30/20 4:14 PM, Laine Stump wrote:
On 4/30/20 2:20 PM, Daniel Henrique Barboza wrote:
On 3/19/20 4:00 PM, Laine Stump wrote:
TL;DR - I'm not as anti-XML as the proposal seems to be, but also not pro-XML. I also (after thinking about it) understand the advantage of putting this in a separate library. So yeah, let's go it!
[...]
Since I've been involved with libvirt's PCI address assignment code for quite a long time (and so there's a lot of knowledge about it embedded in my brain) I *should be* starting to do something with libvirt-devaddr, although I've been deliquent in asking danpb for more specific direction - as I said before this is a completely new medium for me, so I don't really know where to start.
Based on your enthusiasm, I'm guessing you have more experience than me with using go and various go libraries, is that right? If so that could be very helpful in getting it off the ground.
Here are two things that would help enable me to make useful contributions:
1) a basic "source tree for a go library" setup in a libvirt-subproject on gitlab (since gitlab is the official location of libvirt projects now), including basic commit and CI hooks/test cases. I'm guessing we could borrow/steal a lot from what was done by the people who participated in "virt-blocks" last fall. Andrea - any advice/suggestions to give here?
It would be of great help if we can get "inspiration" from another project to get the initial CI/unit test
skeleton.
(A side question - should we put it under the libvirt umbrella on gitlab right away? Or play around in personal trees at first and then later fork it into an official libvirt project?)
I'd rather put it under a personal gitlab tree first. Putting it inside Libvirt umbrella might generate
unrealistic expectations for something that's still on its infancy.
2) a more concrete idea of what the API should look like. This is always the toughest part for me, since it is what the rest of the world sees, so it needs to be intelligible and capable of expansion, and I have a long history of making questionable choices that come back to haunt me (and everybody else! :-P). Since danpb has made good decisions in this area in the past (and since the original proposal is his), I'm thinking/hoping he can help provide direction to minimize mis-steps (on the other hand, I know he's really busy, so maybe he was just hoping that someone else would grab up his proposal and run with it).
My initial plan is to get the logic/APIs design from Libvirt, rename them in a Gopher fashion, re-code
it with Go and call it a day :)
In all seriousness, we have some room to do "not so good" APIs and change them if necessary since it's
a fresh project. In this stage we can start with simplified versions of the use cases danpb described
in the first email of the thread and play by ear.
Thanks,
DHB
