Excerpts from Julia Kreger's message of 2018-05-29 15:41:55 -0400: > On Tue, May 29, 2018 at 3:16 PM, Jay S Bryant <jungleb...@gmail.com> wrote: > > > > > > On 5/29/2018 2:06 PM, Artom Lifshitz wrote: > >> Yeah, I feel like we're all essentially in agreement that nits (of the > >> English mistake of typo type) do need to get fixed, but sometimes > >> (often?) putting the burden of fixing them on the original patch > >> contributor is neither fair nor constructive. > > > > I am ok with this statement if we are all in agreement that doing follow-up > > patches is an acceptable practice. > > > It does feel like there is some general agreement. \o/ > > Putting my Ironic hat on, we've been trying to stress that follow-up > patches are totally acceptable and encouraged. Follow-up patches seem > to land faster in the grand scheme of things and allow series of > patches to move forward in the mean time which is important when a > feature may be spread across 10+ patches > > As for editing just prior to approving, we have learned there can be > absolutely no delay between that edit being made and the patch > approved to land. In essence patches would begin to look like only a > single core reviewer had approved the change they just edited even if > the prior revision had a second core approving the prior revision.. In > my experience, the async nature of waiting for a second core to > sign-off on your edits incurs additional time for nitpicks to occur > and a patch to be blocked. > > Sadly putting the burden on the person approving changes to land is a > bit much as well. I think anyone should be free to propose a follow-up > to any patch, at least that is my opinion and why I wrote the > principles change as I did. >
+1 to that last bit, for sure. In several conversations about this last week we discussed the impression that we don't often see +1 votes with useful comments. A +1 with a follow-up to fix minor issues seems like something we ought to encourage. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev