On 09/24/2018 03:42 PM, Daniel Veillard wrote: > that's next week ! If we want to release around Oct 1st, I would > suggest to enter freeze this Wed, probably in the morning europe time, > then plan for an RC2 friday morning and if everything goes well, have > the final release next monday. > > I hope that works for everybody ! Well, I introduced metadata locking in this release and as usual there are some follow up patches waiting for review: https://www.redhat.com/archives/libvir-list/2018-September/msg01134.html Also, Bjoern reported some issues with the feature (/me wonders if it's s390 specific) and he said he'll debug this week. Anyway, those patches and any patch that he'll write can be viewed as a bug fix and therefore can be merged during freeze.

On 9/25/18 9:38 AM, Daniel Veillard wrote: > On Tue, Sep 25, 2018 at 09:42:20AM +0200, Michal Privoznik wrote: >> On 09/24/2018 03:42 PM, Daniel Veillard wrote: >>> that's next week ! If we want to release around Oct 1st, I would >>> suggest to enter freeze this Wed, probably in the morning europe time, >>> then plan for an RC2 friday morning and if everything goes well, have >>> the final release next monday. >>> >>> I hope that works for everybody ! >> >> Well, I introduced metadata locking in this release and as usual there >> are some follow up patches waiting for review: >> >> https://www.redhat.com/archives/libvir-list/2018-September/msg01134.html >> >> Also, Bjoern reported some issues with the feature (/me wonders if it's >> s390 specific) and he said he'll debug this week. Anyway, those patches >> and any patch that he'll write can be viewed as a bug fix and therefore >> can be merged during freeze. > > Okay, let's proceed as expected, on Friday we can assess if Monday is still > right time for release, or if needed just postpone after Monday. > I've reviewed the patches Michal posted - so that part is a fait accompli ;-) IMO: Since usage of the metadata lock logic requires some amount of setup (e.g. changing a qemu.conf value), it's easy enough to indicate that the support isn't ready. In fact, in Michal's response to my review for patch 22/23: https://www.redhat.com/archives/libvir-list/2018-September/msg00795.html essentially indicates there's more to come in selinux. So, I assume we can still call this "feature" as a work in progress. Perhaps we need a new section in news.xml or some other means to indicate we have "experimental code" with "limited support" (similar to the QEMU development preview and/or the x- prefixed capabilities). IOW: a buyer/user beware if you trip across this, then you are on your own - until of course we fix all the "known" issues. So in summary, I believe the issues raised thus far are primarily metadata locking related, so should we really hold up the release for> something that isn't fully complete or listed in news.xml as a new

On Wed, 2018-09-26 at 11:54 +0200, Michal Privoznik wrote: > On 09/26/2018 01:05 AM, John Ferlan wrote: >> So in summary, I believe the issues raised thus far are primarily >> metadata locking related, so should we really hold up the release for >> something that isn't fully complete or listed in news.xml as a ne >> feature? > > Because if turned on in qemu.conf the feature has possibility of killing > libvirtd every now and then. That's why we need to patch it before the > release. I didn't follow the discussion around the feature itself so I apologize in advance if this ends up being just noise, but can we not just make it so we don't recognize the corresponding qemu.conf option for this release, thus making the feature impossible to turn on for all intents and purposes, and reintroduce the knob once the 4.9.0 cycle starts so that we have plenty of time to work out any remaining kinks in the implementation? That seems like it would be the prudent thing to do.