settingsLogin | Registersettings

[openstack-dev] [nova] Follow up on BCN review cadence discussions

0 votes

I'd like to follow up on the discussions we had in Barcelona around review
cadence. I took a lot away from these discussions, and I thought they were
extremely productive. I think the summary of the concerns was:

Nova is a complex beast, very few people know even most of it well.
There are areas of Nova where mistakes are costly and hard to rectify
later.
A large amount of good code does not merge quickly.
The pool of active core reviewers is very much smaller than the total
pool of contributors.
The barrier to entry for Nova core is very high.

There was more, but I think most people agreed on the above.

Just before summit I pitched a subsystem maintainer model here:

http://lists.openstack.org/pipermail/openstack-dev/2016-September/104093.html

Reading over this again, I still think this is worth trialling: it pushes
the burden of initial detailed review further out, whilst ensuring that a
core will still check that no wider issues have been missed. Bearing in
mind that the primary purpose is to reduce the burden on core reviewers of
any individual patch, I think this will work best if we aggressively push
initial review down as far as possible.

I'm still not sure what the best description of 'domain' is, though. Other
projects seem to have defined this as: the reviewer should, in good faith,
know when they're competent to give a +2 and when they're not. I suspect
this is too loose for us, but I'm sure we could come up with something.

I'd expect the review burden of a maintainer of an active area of code to
be as heavy as a core reviewer's, so this probably shouldn't be taken
lightly. If we were to trial it, I'd also recommend starting with a small
number of maintainers (about 3, perhaps), preferably technical-leaders of
active sub-teams. Any trial should be the topic of a retrospective at the
PTG.

I'd like to re-iterate that what I'd personally like to achieve is:

"Good code should merge quickly."

There are likely other ways to achieve this, and if any of them are better
than this one then I'm in favour. However, I think we can try this one with
limited risk and initial up-front effort.

Thanks,

Matt
--
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 7, 2016 in openstack-dev by Matthew_Booth (4,680 points)   3 6 10
retagged Jan 26, 2017 by admin

8 Responses

0 votes

On Mon, 2016-11-07 at 11:50 +0000, Matthew Booth wrote:
I'd like to follow up on the discussions we had in Barcelona around
review cadence. I took a lot away from these discussions, and I
thought they were extremely productive. I think the summary of the
concerns was:

  Nova is a complex beast, very few people know even most of it well.
  There are areas of Nova where mistakes are costly and hard to
rectify later.
  A large amount of good code does not merge quickly.
  The pool of active core reviewers is very much smaller than the
total pool of contributors.
  The barrier to entry for Nova core is very high.

There was more, but I think most people agreed on the above.

Just before summit I pitched a subsystem maintainer model here:
  http://lists.openstack.org/pipermail/openstack-dev/2016-September/1
04093.html

Reading over this again, I still think this is worth trialling: it
pushes the burden of initial detailed review further out, whilst
ensuring that a core will still check that no wider issues have been
missed. Bearing in mind that the primary purpose is to reduce the
burden on core reviewers of any individual patch, I think this will
work best if we aggressively push initial review down as far as
possible.

I'm still not sure what the best description of 'domain' is, though.
Other projects seem to have defined this as: the reviewer should, in
good faith, know when they're competent to give a +2 and when they're
not. I suspect this is too loose for us, but I'm sure we could come
up with something.

I'd expect the review burden of a maintainer of an active area of
code to be as heavy as a core reviewer's, so this probably shouldn't
be taken lightly. If we were to trial it, I'd also recommend starting
with a small number of maintainers (about 3, perhaps), preferably
technical-leaders of active sub-teams. Any trial should be the topic
of a retrospective at the PTG.

I'd like to re-iterate that what I'd personally like to achieve is:

  "Good code should merge quickly."

There are likely other ways to achieve this, and if any of them are
better than this one then I'm in favour. However, I think we can try
this one with limited risk and initial up-front effort.

I'm just going to leave this here...

https://github.com/torvalds/linux/blob/master/MAINTAINERS
http://dpdk.org/browse/dpdk/tree/MAINTAINERS

We probably don't want to/can't go down the path of hard subtrees
(though we might be already simulating that with the various 'os-'
projects). I do imagine, however, that most folks who have been working
on nova for long enough have a list of domain experts in their heads
already. Would actually putting that on paper really hurt?

Stephen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 8, 2016 by Stephen_Finucane (1,620 points)   3
0 votes

I do imagine, however, that most folks who have been working
on nova for long enough have a list of domain experts in their heads
already. Would actually putting that on paper really hurt?

You mean like this?

https://wiki.openstack.org/wiki/Nova#Developer_Contacts

Those are pretty much the people I look to have sign off on a thing I'm
not completely familiar with before approving something. I'm sure it
could use some updating, of course.

This is linked from the MAINTAINERS file in our tree, by the way.

--Dan


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 8, 2016 by Dan_Smith (9,860 points)   1 2 4
0 votes

On 11/8/2016 11:39 AM, Dan Smith wrote:

I do imagine, however, that most folks who have been working
on nova for long enough have a list of domain experts in their heads
already. Would actually putting that on paper really hurt?

You mean like this?

https://wiki.openstack.org/wiki/Nova#Developer_Contacts

Those are pretty much the people I look to have sign off on a thing I'm
not completely familiar with before approving something. I'm sure it
could use some updating, of course.

This is linked from the MAINTAINERS file in our tree, by the way.

--Dan


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Right, what Dan said. And yes I have a list of people in my head to look
at certain things, especially around PCI, Rbd, live migration, xen,
hyperv, etc. I pull them into reviews regularly when I feel the need.
That's also an indirect way that I can gauge how some people handle
reviews, and what they look for, which in turn gets them on my list of
core candidates, assuming they are actively involved in the project.

I'd also like to say that I dislike the constant comparisons to the
kernel. If people are going to make that comparison, then let's say the
kernel overall is all of OpenStack, and there are subsystems, like
nova/cinder/glance/etc, with their own subsystem maintainers, e.g.
nova-core.

I'd also like to note that I personally don't think the bar to nova core
is as high as some people make it out to be. There is a high standard,
but meeting that standard isn't impossible. For me it means involvement,
maintenance, willingness to own and fix problems, and helpful code
reviews. I'll also say I notice people that -1 more often than people
that +1. That doesn't mean I expect all nova core reviewers to know all
parts of nova, I certainly don't. We have several cores that mostly only
review certain parts of the code, the API being a good example. But they
are definitely experts in that code and own a lot of it, and I trust
them enough to show restraint when reviewing things they aren't experts
on (so a +1 maybe, or +2 on obvious changes).

I'll also note that 'good code' is subjective. What someone thinks is a
worthwhile and useful change might actually break some other part of the
system, or break under a certain configuration. Obviously we don't have
100% CI coverage, we never will. And not everyone has all of this in
their head, that's already been noted. But I don't think it's fair to
say that just because someone thinks 'this is the greatest thing since
sliced bread so let's get it in with a single nova-core +2' is the right
approach. That's my personal opinion.

So I'm still -1 on the subsystem cores idea. I think it would mean
increased throughput but at the expense of fewer nova-cores reviewing a
change with hopefully some context of the broader impact of said change.

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 8, 2016 by Matt_Riedemann (48,320 points)   3 7 20
0 votes

On Nov 8, 2016 1:13 PM, "Matt Riedemann" mriedem@linux.vnet.ibm.com wrote:

On 11/8/2016 11:39 AM, Dan Smith wrote:

I do imagine, however, that most folks who have been working
on nova for long enough have a list of domain experts in their heads
already. Would actually putting that on paper really hurt?

You mean like this?

https://wiki.openstack.org/wiki/Nova#Developer_Contacts

Those are pretty much the people I look to have sign off on a thing I'm
not completely familiar with before approving something. I'm sure it
could use some updating, of course.

This is linked from the MAINTAINERS file in our tree, by the way.

--Dan


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Right, what Dan said. And yes I have a list of people in my head to look
at certain things, especially around PCI, Rbd, live migration, xen, hyperv,
etc. I pull them into reviews regularly when I feel the need. That's also
an indirect way that I can gauge how some people handle reviews, and what
they look for, which in turn gets them on my list of core candidates,
assuming they are actively involved in the project.

I'd also like to say that I dislike the constant comparisons to the
kernel. If people are going to make that comparison, then let's say the
kernel overall is all of OpenStack, and there are subsystems, like
nova/cinder/glance/etc, with their own subsystem maintainers, e.g.
nova-core.

I'd also like to note that I personally don't think the bar to nova core
is as high as some people make it out to be. There is a high standard, but
meeting that standard isn't impossible. For me it means involvement,
maintenance, willingness to own and fix problems, and helpful code reviews.
I'll also say I notice people that -1 more often than people that +1. That
doesn't mean I expect all nova core reviewers to know all parts of nova, I
certainly don't. We have several cores that mostly only review certain
parts of the code, the API being a good example. But they are definitely
experts in that code and own a lot of it, and I trust them enough to show
restraint when reviewing things they aren't experts on (so a +1 maybe, or
+2 on obvious changes).

I'll also note that 'good code' is subjective. What someone thinks is a
worthwhile and useful change might actually break some other part of the
system, or break under a certain configuration. Obviously we don't have
100% CI coverage, we never will. And not everyone has all of this in their
head, that's already been noted. But I don't think it's fair to say that
just because someone thinks 'this is the greatest thing since sliced bread
so let's get it in with a single nova-core +2' is the right approach.
That's my personal opinion.

So I'm still -1 on the subsystem cores idea. I think it would mean
increased throughput but at the expense of fewer nova-cores reviewing a
change with hopefully some context of the broader impact of said change.

Apologies in advance for the email formatting. I'm writing this from my
phone at an airport..

As I mentioned in Barcelona, I'm supportive of a trial of Mr. Booth's idea
with a commitment to gathering data about total review load, merge velocity
and some kind of metric to assess code quality impact. I think we need to
increase the amount of code being merged in specific areas of the Nova
codebase but recognize the inherent danger of opening things up too quickly
on a highly complex piece of source code.

In short, I'd like to get pre and post data and then give the +2 but not +W
concept a shot and see if things improve with regards to merge velocity in
certain areas.

Best,
-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 8, 2016 by Jay_Pipes (59,760 points)   3 10 14
0 votes

On 11/08/2016 12:13 PM, Matt Riedemann wrote:

I'd also like to say that I dislike the constant comparisons to the kernel. If
people are going to make that comparison, then let's say the kernel overall is
all of OpenStack, and there are subsystems, like nova/cinder/glance/etc, with
their own subsystem maintainers, e.g. nova-core.

While there is some merit to that argument, it's not entirely accurate. Nova is
roughly 1/45th the size of the whole kernel source, but the kernel has roughly
1600 separately-maintained subsystems. The "arch/x86" subdirectory in the
kernel source is almost half as big as nova, but there are also
separately-maintained drivers with only a few hundred lines of code.

Something that was mentioned in the summit discussion (but I think it bears
repeating) is that the thing that enables this sort of fine-grained
maintainership in the kernel is that the contracts are better-defined between
the various subsystems. Generally a driver has a limited set of things that it
needs to worry about getting right to interface with the rest of the system, and
other than that it's got free rein in its own sandbox.

That said, I don't know that there's an easy solution to this in nova due to the
fact that it's a distributed system with a central shared data store. Enhancing
a sched filter might require new data, which means modifying the DB model and
the DB migrations, and updating the InstanceNUMATopology object and tweaking
nova-api to request additional attrs, and it might have implications for
upgrade, etc.

Chris


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 8, 2016 by Chris_Friesen (20,420 points)   3 16 24
0 votes

On Tue, 8 Nov 2016, Chris Friesen wrote:

That said, I don't know that there's an easy solution to this in nova due to
the fact that it's a distributed system with a central shared data store.
Enhancing a sched filter might require new data, which means modifying the DB
model and the DB migrations, and updating the InstanceNUMATopology object and
tweaking nova-api to request additional attrs, and it might have implications
for upgrade, etc.

The symptoms that you are describing here are pretty much the crux
of the biscuit.

As much as I think having additional cores or subsystem maintainers
with +2 but not +W would probably be useful, I don't think it will
do much to fix the fundamental problem -- the crux above -- so the
concerns that people have about the risks will continue, will continue
to be valid and can't just be dismissed.

That's a technology crux. There's also a social crux.

It was very clear in BCN that there is significant disagreement in
the community over the volume of code that nova ought to be accepting.
Even in an ideal world where a lot of the roadblocks that people are
experiencing aren't there, there would be disagreement between at least
two (idealized, not literal) camps: One that says any code which doesn't
break stuff and is vaguely in the domain of what nova is about should be
merged and another that says nova should have a clear and focused
vision and contributions that don't fit that vision should be rejected.

At the moment both of these cruxes seem to be treated as things that
are too hard to change, or at least too hard discuss.

On the tech crux some people claim that the decomposition (and the
related boundary hardening) that would lead to safe contracts between
subsystems have already gone as far as they can or taking them
further requires such a huge amount of effort that given resources
and other commitments it can't happen. That smacks of a lack of
imagination and hope.

On the social crux, the impression I got is that people are either
too exhausted, too busy, too angry, or too scared to actually talk
things out and reach a conclusion and instead bitch behind each other's
backs about the lack of agreement and some other core who will either
reject or accept code they shouldn't be. We need to be honest about
this lack of trust if we want to make it better. And we need resolve
the vision of the project, in a concrete fashion.

Until at least one of those cruxes is resolved it's going to be
really hard to make substantial progress and many of the strategies
we try are going to be tactical band-aids.

mdbooth's proposal is somewhat different from some of the other
options because implementing it requires a leap of faith over
both cruxes into what could be a self-reinforcing environment: we will
trust one another because we've said we will, and we will build the
stronger contracts because we need them in order to be able to trust
people, and we will talk about it all (better than we do now) because it
won't work if we don't.

That might work. It could be a mess, but it is better than an
alternative which is feeling increasingly likely: People go elsewhere.

--
Chris Dent ┬─┬ノ( º _ ºノ) https://anticdent.org/
freenode: cdent tw: @anticdent__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 10, 2016 by cdent_plus_os_at_ant (12,800 points)   2 2 5
0 votes

On 11/10/2016 6:15 AM, Chris Dent wrote:
On Tue, 8 Nov 2016, Chris Friesen wrote:

That said, I don't know that there's an easy solution to this in nova
due to the fact that it's a distributed system with a central shared
data store. Enhancing a sched filter might require new data, which
means modifying the DB model and the DB migrations, and updating the
InstanceNUMATopology object and tweaking nova-api to request
additional attrs, and it might have implications for upgrade, etc.

The symptoms that you are describing here are pretty much the crux
of the biscuit.

I really hesitate to even respond to this but I feel the need to, but at
the same time feel as though I'm going to regret it, and it won't help
change anyone's mind, and I'll probably get in trouble from the
Foundation or TC or some other group that monitors what PTLs/cores/etc
say in public. But here goes!

As much as I think having additional cores or subsystem maintainers
with +2 but not +W would probably be useful, I don't think it will
do much to fix the fundamental problem -- the crux above -- so the
concerns that people have about the risks will continue, will continue
to be valid and can't just be dismissed.

That's a technology crux. There's also a social crux.

It was very clear in BCN that there is significant disagreement in
the community over the volume of code that nova ought to be accepting.
Even in an ideal world where a lot of the roadblocks that people are
experiencing aren't there, there would be disagreement between at least
two (idealized, not literal) camps: One that says any code which doesn't
break stuff and is vaguely in the domain of what nova is about should be
merged and another that says nova should have a clear and focused
vision and contributions that don't fit that vision should be rejected.

Believe it or not, those of us that say no to things aren't super happy
saying no to people all of the time. It gets pretty soul-crushing after
awhile. However, for those of us that have worked on Nova for several
years and have seen where saying, 'sure, what the hell, this magical
little vendor snowflake can't possibly harm us, right? btw, don't worry
about maintaining this or CI testing it...we'll trust you to do that out
of tree and report/fix those problems 4 years from now' - that creates
an innate hesitation to more and more magical unicorn vendor-specific
changes. Because it's those kinds of things that get in the way of us
being able to make broader necessary changes later, like with the
placement service/scheduler stuff, and capabilities in the API. With so
much random custom use case code, it's really hard to know what changes
will break something else you thought was unrelated.

Also, we have consistently had operators give feedback at summits that
basically say, 'nova is the most boring project in my deployment, and
that's a good thing' - that's about the best compliment we can get:
stability matters.

And for that matter, the OpenStack community has said that
interoperability matters, and as most have seen we've been working on
removing plugin and extension points over the last several releases to
get to that end. Having said that, it's an entirely whole other topic
unto itself and I have mixed feelings about it personally, i.e. if I'm
building a private devops cloud and don't care about
defcore/refstack/interoperability needed for marketing a product, then
what's wrong with me having configuration and extension point freedom
coming out of my ears? That's a valid point, I understand that. I also
understand that we don't test any of that stuff upstream and we break
it, and then get people shouting at us for breaking things that broke
their snowflake configuration.

At the moment both of these cruxes seem to be treated as things that
are too hard to change, or at least too hard discuss.

Chris, I keep hearing this, especially from you. I don't know what needs
to happen to move past this. We talked about this at length at the BCN
summit. We talked about new contributors and ways to help there at the
ATX summit. So it's not like no one is willing to discuss these things -
we obviously have already. But saying things like 'no one is willing to
even discuss this' is really frustrating to continue hearing, and what's
even more frustrating is I get the feeling that if I even mention that,
it's going to somehow justify the point. "See, he said he's tired of
talking about this, which means he doesn't want to talk about it."

On the tech crux some people claim that the decomposition (and the
related boundary hardening) that would lead to safe contracts between
subsystems have already gone as far as they can or taking them
further requires such a huge amount of effort that given resources
and other commitments it can't happen. That smacks of a lack of
imagination and hope.

I also don't agree with this. I think the sentiment at the summit, if
we're talking about the same thing, was that we've done a lot of
boundary hardening already. There is obviously room for improvement -
but to get there, you're going to have to wade through a LOT of custom
code added by vendors in years past and make sure not to break that.
That's totally fine as a goal, but are you personally going to take up
that challenge and start working on it? If not, then I care less about
hearing about it over and over and continuing to talk about this. We
have priorities each release, and we have several cores working on those
priorities, and with the HPE and Mirantis layoffs we have even fewer
dedicated people able to work on some of these bigger sweeping changes -
and those people had the background on what dragons lay in wait when you
take on some of these big systematic changes. So the point is we have to
prioritize, and I put out of tree enablement less of a priority compared
to the other things we need to get done that operators actually care about.

My main point here is, if you see the opportunity and justification for
the work to completely change something, then by all means, work on that
and keep everyone involved. But I'm tired of hearing how unwilling
people in nova, and by people of course I mean the core team, are to
listening to ideas for positive change and then being thrown under the
bus when we don't have all of the time or priority to nurture all of
those changes.

On the social crux, the impression I got is that people are either
too exhausted, too busy, too angry, or too scared to actually talk
things out and reach a conclusion and instead bitch behind each other's
backs about the lack of agreement and some other core who will either
reject or accept code they shouldn't be. We need to be honest about
this lack of trust if we want to make it better. And we need resolve
the vision of the project, in a concrete fashion.

What's really baffling to me is when I'm in the hallway with you and
Matt Booth and others talking about this stuff face to face in person,
and explaining my side of the issue, and I'm listening to yours, we seem
to all be nodding our heads and agreeing, or at least understanding a
bit better. But then when we get back to the world it's all us vs them
and 'a lot of people are saying nova sucks and they are ready to give up'.

First, the 'speaker of the people' thing gets tiring. We're all working
on the same thing. If people have issues I welcome them to air it out,
but they need to listen to and understand the reply, and try to
understand why we have to say no to things at times, or that we can't
prioritize something.

Second, at least from my view, I get the feeling that there are a few
people beating this drum and complaining about not getting enough
attention and we need to stop everything we're doing whenever they say
something and I just have a hard time with that. What I value most in
nova contributors are people that are doing the dirty work, like
triaging and fixing bugs, fixing technical debt, trying to take on the
dirtier issues to help us move forward, and probably most of all - lots
of quality code reviews. At the end of the day quality code reviews are
going to make you core, and that's what's going to move code through the
system. But people would rather complain about not being core, or the
lack of cores, than actually bust their ass to help out and make core.

Until at least one of those cruxes is resolved it's going to be
really hard to make substantial progress and many of the strategies
we try are going to be tactical band-aids.

mdbooth's proposal is somewhat different from some of the other
options because implementing it requires a leap of faith over
both cruxes into what could be a self-reinforcing environment: we will
trust one another because we've said we will, and we will build the
stronger contracts because we need them in order to be able to trust
people, and we will talk about it all (better than we do now) because it
won't work if we don't.

That might work. It could be a mess, but it is better than an
alternative which is feeling increasingly likely: People go elsewhere.

And finally, the hostage taking approach of everyone going elsewhere is
really wearing on me. If developers have a choice of projects to work on
in OpenStack and for whatever reason find it impossible to work in Nova,
then I frankly think they should move on, for the benefit of both parties.

You know other reasons that people are going to go elsewhere? Because
their company took them off OpenStack, or fired them, because they were
working on OpenStack and they decided as a technology it didn't work
well enough for them and they are going to invest resources elsewhere.
That's why I find it a major distraction to be talking about all of the
ideals of how things would work when instead we have a ton of work to
already get done and we're understaffed, and the future is unsure
regardless - so while I'm here I want to get the major changes in that
we've been working on for years as a project, like cells v2, placement,
and moving off nova-network.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

There, now I feel equally terrible and relieved. I really don't want to
be anyone's barrier, and I feel great when I'm able to help someone out,
new contributor or not. I don't really know what else to say. I know all
of this probably doesn't mean anything and there will be a massive reply
thread discounting each point and exquisite detail about how I'm wrong -
that's fine, it's what I get for taking the bait to respond in detail to
something like this. But I felt the need to do so.

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 10, 2016 by Matt_Riedemann (48,320 points)   3 7 20
0 votes

On Thu, 10 Nov 2016, Matt Riedemann wrote:

What's really baffling to me is when I'm in the hallway with you and Matt
Booth and others talking about this stuff face to face in person, and
explaining my side of the issue, and I'm listening to yours, we seem to all
be nodding our heads and agreeing, or at least understanding a bit better.
But then when we get back to the world it's all us vs them and 'a lot of
people are saying nova sucks and they are ready to give up'.

I'm going to focus on this paragraph because it feels like the most
important part. You seem to think we disagree and that there is
some kind of us or them thing going on. For the most part we agree,
notably on the bit about saying "no". I think we need to do that
even more and I deeply sympathize with the soul crushing nature of
that constantly defensive position. It sucks for everyone involved
yet the truth is that it is probably sucks more for the person who
has to say no frequently (you, Dan, Sean) than it does for the
person who gets to hear "no" every now and again. I'm extremely
sorry all of you have to deal with that, I wish it wasn't the
case and it was easier to communicate the situation or spread the
load. The fact that the two camps that I mentioned have not
resolved to a solid and constantly republished decision makes your
life harder. It doesn't have to be like that.

You've somehow managed to cast me into the position of someone is
"not getting enough attention". I've said time and again that that
is not my concern. I can't be a top ten committer or reviewer (I've
been in and out of both of those groups for the past few months) in
nova and be suffering from a lack of attention.

My concern is with the long term health and pleasantness of Nova and
because of the way I think and the way I understand things my
tendency is to try to find the fundamental reasons things are the
way they are and the ways things are stuck and to try to have
converastions with people to either verify or dismiss that analysis
and to come up with ways to make some kind of forward progress.

This has turned out not to work so well because what it ends being
perceived as either me being a whiny little brat or turning over
rocks that shouldn't be turned because it upsets the status quo.
That's distressing when what I'm trying to do is be helpful. Over the
months I've had some excellent advice from Dan and Sean on how to be
a little more circumspect. I've not always been successful, but
I've tried and I'm thankful for their input.

The thing I learned in BCN, the thing that is the new ingredient in
my analysis (you know, in that continued search for fundamental
reasons things sometimes suck) is that I had the rumors (which I've
known for some time) of the deep rifts in trust that exist inter- and
intra- nova confirmed. How do I know this? Because people kept coming and
telling me: nova contributors, nova cores, people who gave up on
nova, members of the TC, random people I've never heard of. Yes that
'speaker of the people' thing really is tiring!

So when I saw that the conversation about mdbooth's proposal was
"stuck" I thought I would do that thing I try to do: point out what
appears to be some of the underlying reasons. I didn't say "omg all the
nova cores are big jerks and I hate them" because that would be a lie.
I suspect I could have been more explicit about "I'm saying these things
because I'd really like nova to be more fun and successful for everyone
involved".

I guess I assumed that would be inferred on faith. As in it would be
understood because of trust. Why isn't it?

I think we are a "we" and we want the same thing in the end. We may
disagree on how to get there but I view the process of resolving that
disagreement and reaching compromise as the critical path to reaching a
good outcome.

There, now I feel equally terrible and relieved. I really don't want to be
anyone's barrier, and I feel great when I'm able to help someone out, new
contributor or not. I don't really know what else to say. I know all of this
probably doesn't mean anything and there will be a massive reply thread
discounting each point and exquisite detail about how I'm wrong - that's
fine, it's what I get for taking the bait to respond in detail to something
like this. But I felt the need to do so.

I'm glad you did. I wish more people would. I really hate the way
that people think communicating is such a drag and a bad thing. I
know more now than I did before I read your message. Surely that's
a good thing? I'm not sure why you should feel terrible. Did you
tell the truth as you see it? Great. Good on you. I'm grateful. And
I'm glad you feel relieved.

Thank you.

--
Chris Dent ┬─┬ノ( º _ ºノ) https://anticdent.org/
freenode: cdent tw: @anticdent__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 10, 2016 by cdent_plus_os_at_ant (12,800 points)   2 2 5
...