[openstack-dev] [nova] libvirt version_cap, a postmortem

Kashyap Chamarthy kchamart at redhat.com
Mon Sep 1 10:16:40 UTC 2014


On Sat, Aug 30, 2014 at 05:08:16PM +0100, Mark McLoughlin wrote:
> 
> Hey
> 
> The libvirt version_cap debacle continues to come up in conversation and
> one perception of the whole thing appears to be:
> 
>   A controversial patch was "ninjaed" by three Red Hat nova-cores and 
>   then the same individuals piled on with -2s when a revert was proposed
>   to allow further discussion.

As someone who tried to be a little helper to troubleshoot this "live
snapshot" bug (mentioned below) when it surfaced, I've been following
this discussion and ensuing threads about version_cap closely. 

And, FWIW, never in a moment did I feel there was any such intention of
"ninjaing" going on by the said folks, and felt (still do) it was done
in a 'good technical faith'. Maybe my eyes are blindsided by the fact of
observing the work and integrity of these people in different open
source communities over the years.

Thanks for taking time to do this write-up, Mark.

PS: Since email says @redhat.com, hope people reading this thread won't
misinterpret this comment.

> I hope it's clear to everyone why that's a pretty painful thing to hear.
> However, I do see that I didn't behave perfectly here. I apologize for
> that.
> 
> In order to understand where this perception came from, I've gone back
> over the discussions spread across gerrit and the mailing list in order
> to piece together a precise timeline. I've appended that below.
> 
> Some conclusions I draw from that tedious exercise:
> 
>  - Some people came at this from the perspective that we already have 
>    a firm, unwritten policy that all code must have functional written 
>    tests. Others see that "test all the things" is interpreted as a
>    worthy aspiration, but is only one of a number of nuanced factors
>    that needs to be taken into account when considering the addition of
>    a new feature.
> 
>    i.e. the former camp saw Dan Smith's devref addition as attempting 
>    to document an existing policy (perhaps even a more forgiving 
>    version of an existing policy), whereas other see it as a dramatic 
>    shift to a draconian implementation of "test all the things".
> 
>  - Dan Berrange, Russell and I didn't feel like we were "ninjaing a
>    controversial patch" - you can see our perspective expressed in 
>    multiple places. The patch would have helped the "live snapshot" 
>    issue, and has other useful applications. It does not affect the 
>    broader testing debate.
> 
>    Johannes was a solitary voice expressing concerns with the patch, 
>    and you could see that Dan was particularly engaged in trying to 
>    address those concerns and repeating his feeling that the patch was 
>    orthogonal to the testing debate.
> 
>    That all being said - the patch did merge too quickly.
> 
>  - What exacerbates the situation - particularly when people attempt to 
>    look back at what happened - is how spread out our conversations 
>    are. You look at the version_cap review and don't see any of the 
>    related discussions on the devref policy review nor the mailing list 
>    threads. Our disjoint methods of communicating contribute to 
>    misunderstandings.
> 
>  - When it came to the revert, a couple of things resulted in 
>    misunderstandings, hurt feelings and frayed tempers - (a) that our 
>    "retrospective veto revert policy" wasn't well understood and (b) 
>    a feeling that there was private, in-person grumbling about us at 
>    the mid-cycle while we were absent, with no attempt to talk to us 
>    directly.
> 
> 
> To take an even further step back - successful communities like ours
> require a huge amount of trust between the participants. Trust requires
> communication and empathy. If communication breaks down and the pressure
> we're all under erodes our empathy for each others' positions, then
> situations can easily get horribly out of control.

--
/kashyap



More information about the OpenStack-dev mailing list