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

[Jim Somerville]

On 2019-04-18 4:04 p.m., Dean Troyer wrote:
> On Thu, Apr 18, 2019 at 10:22 AM Jim Somerville
> <jim.somerville at 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!

Thanks.

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

Yes, same upstream base.

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

Will do.

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

Yes.

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

Agreed.  I will start the number for both qemu and libvirt at 100 so 
there is no chance of a collision with an earlier released version of 
either package.

-Jim

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