I agree that it's important to set a guideline for this topic. What if the said reviewer is "on vacation or indisposed"? Should a fallback strategy exist for that case? A reviewer could indicate a "delegate core" to review its -2s whenever he has no chance to do it.
Thanks, Ivar. On Fri, Jul 25, 2014 at 5:35 PM, Mandeep Dhami <[email protected]> wrote: > > 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? > > Regards, > Mandeep > ----- > > > > > On Fri, Jul 25, 2014 at 3:14 PM, Kyle Mestery <[email protected]> wrote: > >> On Fri, Jul 25, 2014 at 4:48 PM, Mandeep Dhami <[email protected]> >> wrote: >> > >> > Thanks for the deck Jay, that is very helpful. >> > >> > Also, would it help the process by having some clear >> guidelines/expectations >> > around review time as well? In particular, if you have put a -1 or -2, >> and >> > the issues that you have identified have been addressed by an update >> (or at >> > least the original author thinks that he has addressed your concern), >> is it >> > reasonable to expect that you will re-review in a "reasonable time"? >> This >> > way, the updates can either proceed, or be rejected, as they are being >> > developed instead of accumulating in a backlog that we then try to get >> > approved on the last day of the cut-off? >> > >> I agree, if someone puts a -2 on a patch stressing an issue and the >> committer has resolved those issues, the -2 should also be resolved in >> a timely manner. If the issue can't be resolved in the review itself, >> as this wiki page [1] indicates, the issue should be moved to the >> mailing list. >> >> Thanks, >> Kyle >> >> [1] https://wiki.openstack.org/wiki/CodeReviewGuidelines >> >> > Regards, >> > Mandeep >> > >> > >> > >> > On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon <[email protected]> >> wrote: >> >> >> >> ----- Original Message ----- >> >> > From: "Jay Pipes" <[email protected]> >> >> > To: [email protected] >> >> > >> >> > On 07/24/2014 10:05 AM, CARVER, PAUL wrote: >> >> > > Alan Kavanagh wrote: >> >> > > >> >> > >> If we have more work being put on the table, then more Core >> >> > >> members would definitely go a long way with assisting this, we >> cant >> >> > >> wait for folks to be reviewing stuff as an excuse to not get >> >> > >> features landed in a given release. >> >> > >> >> > We absolutely can and should wait for folks to be reviewing stuff >> >> > properly. A large number of problems in OpenStack code and flawed >> design >> >> > can be attributed to impatience and pushing through code that wasn't >> >> > ready. >> >> > >> >> > I've said this many times, but the best way to get core reviews on >> >> > patches that you submit is to put the effort into reviewing others' >> >> > code. Core reviewers are more willing to do reviews for someone who >> is >> >> > clearly trying to help the project in more ways than just pushing >> their >> >> > own code. Note that, Alan, I'm not trying to imply that you are >> guilty >> >> > of the above! :) I'm just recommending techniques for the general >> >> > contributor community who are not on a core team (including myself!). >> >> >> >> I agree with all of the above, I do think however there is another >> >> un-addressed area where there *may* be room for optimization - which >> is how >> >> we use the earlier milestones. I apologize in advance because this is >> >> somewhat tangential to Alan's points but I think it is relevant to the >> >> general frustration around what did/didn't get approved in time for the >> >> deadline and ultimately what will or wont get reviewed in time to make >> the >> >> release versus being punted to Kilo or even further down the road. >> >> >> >> We land very, very, little in terms of feature work in the *-1 and *-2 >> >> milestones in each release (and this is not just a Neutron thing). Even >> >> though we know without a doubt that the amount of work currently >> approved >> >> for J-3 is not realistic we also know that we will land significantly >> more >> >> features in this milestone than the other two that have already been >> and >> >> gone, which to my way of thinking is actually kind of backwards to the >> ideal >> >> situation. >> >> >> >> What is unclear to me however is how much of this is a result of >> >> difficulty identifying and approving less controversial/more >> straightforward >> >> specifications quickly following summit (keeping in mind this time >> around >> >> there was arguably some additional delay as the *-specs repository >> approach >> >> was bedded down), an unavoidable result of human nature being to >> *really* >> >> push when there is a *hard* deadline to beat, or just that these >> earlier >> >> milestones are somewhat impacted from fatigue from the summit (I know >> a lot >> >> of people also try to take some well earned time off around this >> period + of >> >> course many are still concentrated on stabilization of the previous >> >> release). As a result it's unclear whether there is anything concrete >> that >> >> can be done to change this but I thought I would bring it up in case >> anyone >> >> else has any bright ideas! >> >> >> >> > [SNIP] >> >> >> >> > > We ought to (in my personal opinion) be supplying core reviewers to >> >> > > at least a couple of OpenStack projects. But one way or another we >> >> > > need to get more capabilities reviewed and merged. My personal top >> >> > > disappointments are with the current state of IPv6, HA, and QoS, >> but >> >> > > I'm sure other folks can list lots of other capabilities that >> >> > > they're really going to be frustrated to find lacking in Juno. >> >> > >> >> > I agree with you. It's not something that is fixable overnight, or >> by a >> >> > small group of people, IMO. It's something that needs to be >> addressed by >> >> > the core project teams, acting as a group in order to reduce review >> wait >> >> > times and ensure that there is responsiveness, transparency and >> >> > thoroughness to the review (code as well as spec) process. >> >> > >> >> > I put together some slides recently that have some insights and >> >> > (hopefully) some helpful suggestions for both doing and receiving >> code >> >> > reviews, as well as staying sane in the era of corporate agendas. >> >> > Perhaps folks will find it useful: >> >> > >> >> > http://bit.ly/navigating-openstack-community >> >> >> >> As an aside this is a very well put together deck, thanks for sharing! >> >> >> >> -Steve >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> [email protected] >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > [email protected] >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
