don't hesitate to "release early and often" that work of yours so that you can get early feedback and make reviewing easier.
Total agreement here. Unfortunately, I am basically rebasing the entire repo so none of my changes are in a fully functional state and not in a place where I could create a PR. If you want to track my progress check out this repo.
providing makefiles for more package managers is not a priority in my eyes.
For me, this one of my main priorities. I am of an 'open-source first' mentality and placing the burden on each distributions package maintainers is a bit backward in my eyes. Citrix already supports enterprise clients, and basically only updates rpm and deb packages. My goal is to bring all opensource, free distributions up to the same level of compatibility and support as enterprise. In addition, by placing the burden on each distributions team, updates have been largely ignored. Freebsd, Fedora, Ubuntu, CentOS, etc all have xe-guest-utilities that are in some cases, years out of date.
One of my priorities, however, is to build our own binaries instead of using those provided by Citrix
I'm a little confused about this statement. Since I am patching security issues in the go code itself, we will have to compile these into our own binaries, and therefore a separate package(not called xe-guest-utilities for obvious versioning conflict issues). Makefiles will be separated in a similar-ish way to how they are in the Citrix Repo. The core makefile creates a secure temp go build environment, then generates the target binaries. From there, each distribution has it own makefile (in Citrix repo mk/Makefile.deb and mk/Makefile.rpm), which then take the compiled binaries and collects the other various files needed to package these into a xe-guest-utilities.deb or xe-guest-utilities.deb.
If you want to help on that front, the ideal situation would be to be able to build them in Koji.
I can't speak to Koji, I've never used it. Honestly, building the binaries is like the easiest part of this process(you just need to setup some gopaths). I was just gonna use the tool wrote to natively build a package for each distro in its target distro(IE build fedora packages inside fedora), then return the compiled packages to an endpoint.
will you stay around for the next few years to continue maintaining that code, fix bugs, help review PRs, etc?
Just depends if the work I've done gets adopted or not. I usually take on projects when they have a direct impact on my life and also helps the community. I use a lot of distros and I'm really sick of having second rate drivers on non deb and rpm based systems. It solves a problem for me so I will maintain them for at least that reason. My hope obviously, is that this work will be helpful for people using none deb and rpm systems as well, I just try not to get too attached to how many people are using an opensource project I write. It can be really discouraging if you put hundreds of hours into a project for the community that then is never used.
I will definitely be in touch when we are ready to test on SLES!
