On 06/25/2014 07:53 AM, Martin Geisler wrote: > Sean Dague <s...@dague.net> writes: > >> On 06/25/2014 03:56 AM, Martin Geisler wrote: >>> >>> In the Mercurial project we accept contributions sent as patches >>> only. There it's common for the core developers to fix the commit >>> message locally before importing a patch. That makes it quick to fix >>> these problems and I think that this workflow puts less work on the >>> core maintainers. >>> >>> With Gerrit, it seems that simply fixing the commit message in the >>> web interface could work. I know that a patch submitter can update it >>> online, but I don't know if (core) reviewers can also just update it? >> >> Anyone can actually upload a 2nd patch, which includes changing the >> commit message. We just mostly have a culture of not rewriting >> people's patches, for better or worse. > > Thanks, I did not know about this possibility. > >>> (Updating the patch in Gerrit would "go behind the back" of the >>> submitter who would then have to rebase any additional work he has >>> done on the branch. So this is not 100% pain free.) >> >> That's often the challenge, it works fine if the original author is >> actually paying attention, and does a git review -d instead of just >> using their local branch. But is many cases that's not happening. >> (Also it's completely off book for how we teach folks to use git >> --amend in the base case). >> >> I've had instances of working with someone where even though we were >> talking on IRC during the whole thing, they kept overwriting the fix I >> was sticking in for them to get the test fixed. So typically you only >> want to do this with really advanced developers, with heads up that >> you pushed over them. > > I would guess that these developers would also typically respond quickly > and positively if you point out typos in the commit message. So this > makes the extra round trip less of an issue. > > I've only submitted some small trivial patches. As far as I could tell, > Gerrit triggered a full test cycle when I just changed the commit > message. That surprised me and made the reviews more time-consuming, > especially because Jenkins would fail fairly often because of what looks > like heisenbugs to me.
We track them here - http://status.openstack.org/elastic-recheck/ - help always appreciated in fixing them. Most of them are actually race conditions that exist in OpenStack. I think optimizing the zuul path for commit message only changes would be useful. Today the pipeline only knows that there was a change. That's not something anyone's gotten around to yet. >> I do also think people often get grumpy about other people rewriting >> their code. Which I think is just human, so erring on the side of >> giving feedback instead of taking it over is I think the right thing >> to do. > > I agree that such tricks are likely to do more harm than good for new > contributors. > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev