On 2019-04-18 4:04 p.m., Dean Troyer wrote:
On Thu, Apr 18, 2019 at 10:22 AM Jim Somerville <jim.somerville@windriver.com> wrote:
I've finished reducing the patches on libvirt and qemu. I was able to get rid of virtually all of the RHEL patches, replacing them with just a minor "support for running on CentOS" patch or two. This will make our lives a lot easier moving to newer versions. qemu went from 97 patches down to 14, and libvirt from 23 to 13. The STX patches themselves required very little rework, this was mostly a testing exercise in the container realm with things changing frequently, making it quite challenging.
Awesome!
Once you're satisfied with the review, I'll issue pull requests. Once you've pulled and created new branches, I'll follow up with the two commits, one referring to the new branches in the manifest, and the other with minor changes to the qemu spec file in the stx-integ repo. Linked so they both go in together.
It looks like these are on the same upstream base version, correct? We'll have to add a suffix but that isn't a problem. I'll use '-N' for that so it doesn't look like part of the upstream version (we used '.N' for the Nova stable branch in stx-nova, /me kicks self). I have created stx-qemu/stx/v3.0.0-1 and stx-libvirt/stx/v4.7.0-1. Fire away with the PRs.
Hi Dean, Saul finished approving the new branch contents, so they're ready to merge into your newly created -1 branch versions, assuming you're good with them as well. -Jim
One issue concerns me a bit, and that is the tis patch number. It starts counting from the last upstream commit, and with me removing patches, it is now lower than it used to be. If this is a real concern I could just add a fixed 100 to the gitrevcount in both qemu and libvirt build_data files, guaranteeing package versions will not collide with ones in the past. Your thoughts?
Is this that number that is supposed to be based on the patch count? I think we should get rid of that idea and just increment it every time it need to be incremented. Overloading things like that just makes everything more brittle.
Also...
I still want to encourage folks to do dev work in the primary places (Gerrit and starlngx-staging on GitHub), this is a very important part of The Four Opens[0] that is fundamental to being part of the OpenStack Foundation. In this case it isn't so much development as cleanup but it still counts as working in the open. Updating a WIP PR is just as doable as a WIP Gerrit review as things progress. And that lets people find the work without having to know beforehand where it is, even as in this case it was on GitHub anyway.
[I am trying to not pick on Jim specifically here but I did recently say something in a meeting about this particular work and I thought this was a good place to expand on why I feel so strongly on this topic. These principles are fundamental to StarlingX being accepted as an OpenStack Foundation project and we _will_ be judged on things like this. We already are (informally) in fact...]
dt
[0] The Four Opens: https://governance.openstack.org/tc/reference/opens.html