Open Stack

I like the pull-approve behavior (no reset) more...

On Wed, Feb 13, 2019 at 9:34 AM zhangwei (CR) <zhangwei555 at huawei.com>
wrote:

> I think we can try first with "reset" for security.
> We can still change it back if we find that it makes things too
> complicated.
>
> -----邮件原件-----
> 发件人: Venegas Munoz, Jose Carlos [mailto:
> jose.carlos.venegas.munoz at intel.com]
> 发送时间: 2019年2月13日 4:36
> 收件人: Whaley, Graham <graham.whaley at intel.com>; kata-dev <
> kata-dev at lists.katacontainers.io>
> 主题: Re: [kata-dev] should github reset ack count on PR change?
>
> 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.
> -
> Carlos
>
>
> -----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.
>
> Graham
>
>
> ---------------------------------------------------------------------
> 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
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>


-- 
--

Xu Wang
CTO & Cofounder, Hyper
github/twitter/wechat: @gnawux
http://hyper.sh

Hyper_: Make VM run like container
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190213/fedc68e5/attachment.html>