<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">Le 07/12/2014 23:27, Dan Smith a
écrit :<br>
</div>
<blockquote cite="mid:5484D434.7080507@danplanet.com" type="cite">
<blockquote type="cite">
<pre wrap="">The argument boils down to there is a communications cost to adding
someone to core, and therefore there is a maximum size before the
communications burden becomes to great.
</pre>
</blockquote>
<pre wrap="">
I'm definitely of the mindset that the core team is something that has a
maximum effective size. Nova is complicated and always changing; keeping
everyone on top of current development themes is difficult. Just last
week, we merged a patch that bumped the version of an RPC API without
making the manager tolerant of the previous version. That's a theme
we've had for a while, and yet it was still acked by two cores.
A major complaint I hear a lot is "one core told me to do X and then
another core told me to do !X". Obviously this will always happen, but I
do think that the larger and more disconnected the core team becomes,
the more often this will occur. If all the cores reviewed at the rate of
the top five and we still had a throughput problem, then evaluating the
optimal size would be a thing we'd need to do. However, even at the
current size, we have (IMHO) communication problems, mostly uninvolved
cores, and patches going in that break versioning rules. Making the team
arbitrarily larger doesn't seem like a good idea to me.
</pre>
</blockquote>
<br>
As a non-core, I can't speak about how cores communicate within the
team. That said, I can just say it is sometimes very hard to review
all the codepaths that Nova has, in particular when some new rules
are coming in (for example, API microversions, online data
migrations or reducing the tech debt in the Scheduler).<br>
<br>
As a consequence, I can understand that some people can do mistakes
when reviewing a specific change because they are not experts or
because they missed some important non-written good practice.<br>
That said, I think this situatiion doesn't necessarly mean that it
can't be improved by simple rules.<br>
<br>
For example, the revert policy is a good thing : errors can happen,
and admitting that it's normal that a revert can happen in the next
couple of days seems fine by me. Also, why not considering that some
cores are more experts than others in a single codepath ? I mean, we
all know who to address if we have some specific questions about a
change (like impacting virt drivers, objects, or API). So, why a
change wouldn't be at least +1'd by these expert cores before
*approving* it ?<br>
<br>
As Nova is growing, I'm not sure if it's good to cap the team. IMHO,
mistakes are human, that shouldn't be the reason why the team is not
growing, but rather how we can make sure that disagreements wouldn't
be a problem.<br>
<br>
(Now going back in my cavern)<br>
-Sylvain<br>
<br>
<br>
<blockquote cite="mid:5484D434.7080507@danplanet.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I will say that I am disappointed that we have cores who don't
regularly attend our IRC meetings. That makes the communication much
more complicated.
</pre>
</blockquote>
<pre wrap="">
Agreed. We alternate the meeting times such that this shouldn't be hard,
IMHO.
--Dan
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>