[kata-dev] should github reset ack count on PR change?

Venegas Munoz, Jose Carlos jose.carlos.venegas.munoz at intel.com
Tue Feb 12 20:35:44 UTC 2019

I feel more secure that if the PR changes would need to re-ack.

So +1 for reset ( this could slow our merge process), I hope not a lot. 

-----Original Message-----
From: Whaley, Graham [mailto:graham.whaley at intel.com] 
Sent: Tuesday, February 12, 2019 11:59 AM
To: kata-dev <kata-dev at lists.katacontainers.io>
Subject: [kata-dev] should github reset ack count on PR change?

Hi kata-devs,
 I'd like to cast a shout out for opinions on a bit of github PR workflow here....
 With the move from pullapprove to github to do the ack/nack counting, I had to make a decision on one of the github setup options.
 There is a tickbox that basically says 'if the PR changes, drop all existing acks and reset to 0'.
 We had a mixture of that being on/off across the repos. I set it to 'on' for them all, as notionally that seems like the right thing to do for a 'perfect workflow' (that is - if somebody changed the PR, how can you know your ack still applies etc. etc.).

But, that is not how we had pullapprove working. Acks were sticky in pullapprove.
And, tbh, most of the time the PRs are being updated to fix little things, and existing acks are mostly (99% of the time) OK to stick...

What do we think - do we want acks sticky or not... I'm fairly OK either way, and will go setup/check github once we make a decision.


Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

kata-dev mailing list
kata-dev at lists.katacontainers.io

More information about the kata-dev mailing list