Hi Jim, This looks like great work and a strong effort to reduce patches, thanks! On 4/18/19 8:21 AM, Jim Somerville wrote:
Hi Dean and other interested parties,
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.
I have not yet reviewed your repos, but want to know if you have given thoughts to upstreaming any of the remaining patches to qemu or libvirt as appropriate?
This passed our regular sanity test run, and we subsequently did a full regression test run. All of the interesting failures in the regression run were explainable via existing bug reports. I feel reasonably confident that this isn't going to break anything, but, hey, famous last words and all that.
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.
Is there a reason to not issue the pull requests directly to the stx-staging repos now if your ready?
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?
At the last F2F in Chandler the discussion about TIS_PATCH_VER determined that it was a sequential version number, and not a count of patches. If this was a rebase with a version change, then you would start at 1 again, but since this is a rebase without, you should bump TIS_PATCH_VER by 1.
https://github.com/jsomervi/stx-qemu/commits/v3.0.0-patch-reduction-1 https://github.com/jsomervi/stx-libvirt-1/commits/v4.7.0-patch-reduction-1
Thanks Sau!
Thanks,
-Jim