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

[Dean Troyer]

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!

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

> 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

-- 
Dean Troyer
dtroyer at gmail.com