Open Stack

On 06/25/2014 07:53 AM, Martin Geisler wrote:
> 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.

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140625/cebc4b5d/attachment.pgp>