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

[Jim Somerville]

On 2019-04-18 12:48 p.m., Saul Wold wrote:
> Hi Jim,
> 
> This looks like great work and a strong effort to reduce patches, thanks!

Thanks Saul, appreciated.

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

I haven't given it much thought.  Not being the actual author of most of 
them, I don't feel all that qualified to embark on the sales job of 
getting them in upstream.

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

No reason other than I just wanted folks to have a chance to look/review 
before I pestered the stx-staging repo controllers with pull requests.

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

The way it is currently done in libvirt/qemu is via the GITREVCOUNT 
mechanism.  This change I'm making is essentially just rewriting a repo 
branch, and doesn't include an underlying version change to the code 
such as 3.0.0 to 3.0.1.  I could abandon GITREVCOUNT and just set 
TIS_PATCH_VER to a version manually, 98 for qemu and 24 for libvirt.

-Jim

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