Open Stack

Sean Dague <sean at 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.

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

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140625/9633bc54/attachment.pgp>