<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks Jay. I agree with your position on it, and that is exactly what I would expect as the process in a collaborative community. That "feels like the right way" ;-)</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Unfortunately, there have been situations where we have had to ask a reviewer multiple times to re-review the code (after issues identified in a previous review have been addressed). Then you struggle between "am I pestering the reviewer" vs. "what more can we do/needs to be done, please help us understand" - and absence of that feedback leads to discouragement for new contributors and piling up of patches for the big deluge near the cut-off deadlines. My suggestion was to deal with outliers like that.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If there was a clear guideline, that facilitated the smooth flow of patches and an automated reminder that did not make the person asking for reviews feel that he/she is pestering, that might help. Or maybe if we update infra to report on avg. number of days that a negative review was not re-reviewed after a new patch, we could just address the outliers when we see them. Just an idea to address the outliers, not the normal flow.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Regards,</div><div class="gmail_default" style="font-size:small">Mandeep</div><div class="gmail_default" style="font-size:small">
-----</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 26, 2014 at 10:19 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 07/25/2014 05:48 PM, Mandeep Dhami wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the deck Jay, that is very helpful.<br>
<br>
Also, would it help the process by having some clear<br>
guidelines/expectations around review time as well? In particular, if<br>
you have put a -1 or -2, and the issues that you have identified have<br>
been addressed by an update (or at least the original author thinks that<br>
he has addressed your concern), is it reasonable to expect that you will<br>
re-review in a "reasonable time"? This way, the updates can either<br>
proceed, or be rejected, as they are being developed instead of<br>
accumulating in a backlog that we then try to get approved on the last<br>
day of the cut-off?<br>
</blockquote>
<br></div>
Guilty as charged, Mandeep. :( If I have failed to re-review something in a timely manner, please don't hesitate to either find me on IRC or send me an email saying "hey, don't forget about XYZ". People get behind on reviews and sometimes things slip the mind. A gentle reminder is all that is needed, usually.<br>
<br>
As for a hard number of days before sending an email notification, that might be possible, but it's not like we all have our vacation reminders linked in to Gerrit ;) I think a more personal email or IRC request for specific reviews is more appropriate.<br>
<br>
Best,<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon <<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a><br></div><div class="">
<mailto:<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>>> wrote:<br>
<br>
----- Original Message -----<br></div><div><div class="h5">
> From: "Jay Pipes" <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a> <mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>><br>
> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<u></u>org</a><br>
<mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a>><br>
><br>
> On 07/24/2014 10:05 AM, CARVER, PAUL wrote:<br>
> > Alan Kavanagh wrote:<br>
> ><br>
> >> If we have more work being put on the table, then more Core<br>
> >> members would definitely go a long way with assisting this, we<br>
cant<br>
> >> wait for folks to be reviewing stuff as an excuse to not get<br>
> >> features landed in a given release.<br>
><br>
> We absolutely can and should wait for folks to be reviewing stuff<br>
> properly. A large number of problems in OpenStack code and flawed<br>
design<br>
> can be attributed to impatience and pushing through code that<br>
wasn't ready.<br>
><br>
> I've said this many times, but the best way to get core reviews on<br>
> patches that you submit is to put the effort into reviewing others'<br>
> code. Core reviewers are more willing to do reviews for someone<br>
who is<br>
> clearly trying to help the project in more ways than just pushing<br>
their<br>
> own code. Note that, Alan, I'm not trying to imply that you are<br>
guilty<br>
> of the above! :) I'm just recommending techniques for the general<br>
> contributor community who are not on a core team (including myself!).<br>
<br>
I agree with all of the above, I do think however there is another<br>
un-addressed area where there *may* be room for optimization - which<br>
is how we use the earlier milestones. I apologize in advance because<br>
this is somewhat tangential to Alan's points but I think it is<br>
relevant to the general frustration around what did/didn't get<br>
approved in time for the deadline and ultimately what will or wont<br>
get reviewed in time to make the release versus being punted to Kilo<br>
or even further down the road.<br>
<br>
We land very, very, little in terms of feature work in the *-1 and<br>
*-2 milestones in each release (and this is not just a Neutron<br>
thing). Even though we know without a doubt that the amount of work<br>
currently approved for J-3 is not realistic we also know that we<br>
will land significantly more features in this milestone than the<br>
other two that have already been and gone, which to my way of<br>
thinking is actually kind of backwards to the ideal situation.<br>
<br>
What is unclear to me however is how much of this is a result of<br>
difficulty identifying and approving less controversial/more<br>
straightforward specifications quickly following summit (keeping in<br>
mind this time around there was arguably some additional delay as<br>
the *-specs repository approach was bedded down), an unavoidable<br>
result of human nature being to *really* push when there is a *hard*<br>
deadline to beat, or just that these earlier milestones are somewhat<br>
impacted from fatigue from the summit (I know a lot of people also<br>
try to take some well earned time off around this period + of course<br>
many are still concentrated on stabilization of the previous<br>
release). As a result it's unclear whether there is anything<br>
concrete that can be done to change this but I thought I would bring<br>
it up in case anyone else has any bright ideas!<br>
<br>
> [SNIP]<br>
<br>
> > We ought to (in my personal opinion) be supplying core reviewers to<br>
> > at least a couple of OpenStack projects. But one way or another we<br>
> > need to get more capabilities reviewed and merged. My personal top<br>
> > disappointments are with the current state of IPv6, HA, and<br>
QoS, but<br>
> > I'm sure other folks can list lots of other capabilities that<br>
> > they're really going to be frustrated to find lacking in Juno.<br>
><br>
> I agree with you. It's not something that is fixable overnight,<br>
or by a<br>
> small group of people, IMO. It's something that needs to be<br>
addressed by<br>
> the core project teams, acting as a group in order to reduce<br>
review wait<br>
> times and ensure that there is responsiveness, transparency and<br>
> thoroughness to the review (code as well as spec) process.<br>
><br>
> I put together some slides recently that have some insights and<br>
> (hopefully) some helpful suggestions for both doing and receiving<br>
code<br>
> reviews, as well as staying sane in the era of corporate agendas.<br>
> Perhaps folks will find it useful:<br>
><br>
> <a href="http://bit.ly/navigating-openstack-community" target="_blank">http://bit.ly/navigating-<u></u>openstack-community</a><br>
<br>
As an aside this is a very well put together deck, thanks for sharing!<br>
<br>
-Steve<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br></div></div>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><div class=""><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>