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
