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" ;-)
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. 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. Regards, Mandeep ----- On Sat, Jul 26, 2014 at 10:19 AM, Jay Pipes <jaypi...@gmail.com> wrote: > On 07/25/2014 05:48 PM, Mandeep Dhami 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? >> > > 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. > > 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. > > Best, > -jay > > On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon <sgor...@redhat.com >> <mailto:sgor...@redhat.com>> wrote: >> >> ----- Original Message ----- >> > From: "Jay Pipes" <jaypi...@gmail.com <mailto:jaypi...@gmail.com>> >> > To: openstack-dev@lists.openstack.org >> <mailto:openstack-dev@lists.openstack.org> >> > >> > 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 >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev