[Starlingx-discuss] V1 Review Request: Story 29990: libvirt and qemu patch reduction

[Saul Wold]

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
> 
> 
> 
> 
>