[openstack-dev] [tc][all] A culture change (nitpicking)

Doug Hellmann doug at doughellmann.com
Tue May 29 19:55:41 UTC 2018

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 <jungleboyj at 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.


More information about the OpenStack-dev mailing list