<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What would be a good guideline for "timely manner"? I would recommend something like 2-3 days unless the reviewer is on vacation or is indisposed. Is it possible to update gerrit/jenkins to send reminders to reviewers in such a scenario?</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 class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 25, 2014 at 3:14 PM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.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 Fri, Jul 25, 2014 at 4:48 PM, Mandeep Dhami <<a href="mailto:dhami@noironetworks.com">dhami@noironetworks.com</a>> wrote:<br>
><br>
> Thanks for the deck Jay, that is very helpful.<br>
><br>
> Also, would it help the process by having some clear guidelines/expectations<br>
> around review time as well? In particular, if you have put a -1 or -2, and<br>
> the issues that you have identified have been addressed by an update (or at<br>
> least the original author thinks that he has addressed your concern), is it<br>
> reasonable to expect that you will re-review in a "reasonable time"? This<br>
> way, the updates can either proceed, or be rejected, as they are being<br>
> developed instead of accumulating in a backlog that we then try to get<br>
> approved on the last day of the cut-off?<br>
><br>
</div>I agree, if someone puts a -2 on a patch stressing an issue and the<br>
committer has resolved those issues, the -2 should also be resolved in<br>
a timely manner. If the issue can't be resolved in the review itself,<br>
as this wiki page [1] indicates, the issue should be moved to the<br>
mailing list.<br>
<br>
Thanks,<br>
Kyle<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/CodeReviewGuidelines" target="_blank">https://wiki.openstack.org/wiki/CodeReviewGuidelines</a><br>
<div class="HOEnZb"><div class="h5"><br>
> Regards,<br>
> Mandeep<br>
><br>
><br>
><br>
> On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon <<a href="mailto:sgordon@redhat.com">sgordon@redhat.com</a>> wrote:<br>
>><br>
>> ----- Original Message -----<br>
>> > From: "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>><br>
>> > To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.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 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 design<br>
>> > can be attributed to impatience and pushing through code that wasn't<br>
>> > 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 who is<br>
>> > clearly trying to help the project in more ways than just pushing their<br>
>> > own code. Note that, Alan, I'm not trying to imply that you are 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 is how<br>
>> we use the earlier milestones. I apologize in advance because this is<br>
>> somewhat tangential to Alan's points but I think it is relevant to the<br>
>> general frustration around what did/didn't get approved in time for the<br>
>> deadline and ultimately what will or wont get reviewed in time to make the<br>
>> release versus being punted to Kilo or even further down the road.<br>
>><br>
>> We land very, very, little in terms of feature work in the *-1 and *-2<br>
>> milestones in each release (and this is not just a Neutron thing). Even<br>
>> though we know without a doubt that the amount of work currently approved<br>
>> for J-3 is not realistic we also know that we will land significantly more<br>
>> features in this milestone than the other two that have already been and<br>
>> gone, which to my way of thinking is actually kind of backwards to the ideal<br>
>> 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 straightforward<br>
>> specifications quickly following summit (keeping in mind this time around<br>
>> there was arguably some additional delay as the *-specs repository approach<br>
>> was bedded down), an unavoidable result of human nature being to *really*<br>
>> push when there is a *hard* deadline to beat, or just that these earlier<br>
>> milestones are somewhat impacted from fatigue from the summit (I know a lot<br>
>> of people also try to take some well earned time off around this period + of<br>
>> course many are still concentrated on stabilization of the previous<br>
>> release). As a result it's unclear whether there is anything concrete that<br>
>> can be done to change this but I thought I would bring it up in case anyone<br>
>> 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 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, or by a<br>
>> > small group of people, IMO. It's something that needs to be addressed by<br>
>> > the core project teams, acting as a group in order to reduce 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 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-openstack-community</a><br>
>><br>
>> As an aside this is a very well put together deck, thanks for sharing!<br>
>><br>
>> -Steve<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>