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.
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@intel.com] Sent: Tuesday, February 12, 2019 11:59 AM To: kata-dev <kata-dev@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@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
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@intel.com] 发送时间: 2019年2月13日 4:36 收件人: Whaley, Graham <graham.whaley@intel.com>; kata-dev <kata-dev@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@intel.com] Sent: Tuesday, February 12, 2019 11:59 AM To: kata-dev <kata-dev@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@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
I like the pull-approve behavior (no reset) more... On Wed, Feb 13, 2019 at 9:34 AM zhangwei (CR) <zhangwei555@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@intel.com] 发送时间: 2019年2月13日 4:36 收件人: Whaley, Graham <graham.whaley@intel.com>; kata-dev < kata-dev@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@intel.com] Sent: Tuesday, February 12, 2019 11:59 AM To: kata-dev <kata-dev@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@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@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
Vote so far is 2 for reset, and 1 for leave-alone… I will leave it on ‘reset on PR change’ right now, and we will see how it works out. Thanks for the replies! From: Xu Wang [mailto:xu@hyper.sh] Sent: Wednesday, February 13, 2019 6:47 AM To: zhangwei (CR) <zhangwei555@huawei.com> Cc: Venegas Munoz, Jose Carlos <jose.carlos.venegas.munoz@intel.com>; Whaley, Graham <graham.whaley@intel.com>; kata-dev <kata-dev@lists.katacontainers.io> Subject: Re: [kata-dev] 答复: should github reset ack count on PR change? I like the pull-approve behavior (no reset) more... On Wed, Feb 13, 2019 at 9:34 AM zhangwei (CR) <zhangwei555@huawei.com<mailto:zhangwei555@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@intel.com<mailto:jose.carlos.venegas.munoz@intel.com>] 发送时间: 2019年2月13日 4:36 收件人: Whaley, Graham <graham.whaley@intel.com<mailto:graham.whaley@intel.com>>; kata-dev <kata-dev@lists.katacontainers.io<mailto:kata-dev@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@intel.com<mailto:graham.whaley@intel.com>] Sent: Tuesday, February 12, 2019 11:59 AM To: kata-dev <kata-dev@lists.katacontainers.io<mailto:kata-dev@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@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@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<http://hyper.sh/> Hyper_: Make VM run like container --------------------------------------------------------------------- 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.
Having lived with this for a while now, I've decided I'm with Xu - I don't like the current behaviour: it's confusing ("wait, didn't I ack that PR yesterday?") and information is being lost (the ack history). I think there is value in others being able to see that a PR *was* ack'd, even if it's subsequently been updated. It's also clear to all which set of people could/should be pinged for a fresh ack as github shows the timeline of events clearly on the PR. Cheers, James Le mer. 13 févr. 2019 à 10:45, Whaley, Graham <graham.whaley@intel.com> a écrit :
Vote so far is 2 for reset, and 1 for leave-alone…
I will leave it on ‘reset on PR change’ right now, and we will see how it works out.
Thanks for the replies!
*From:* Xu Wang [mailto:xu@hyper.sh] *Sent:* Wednesday, February 13, 2019 6:47 AM *To:* zhangwei (CR) <zhangwei555@huawei.com> *Cc:* Venegas Munoz, Jose Carlos <jose.carlos.venegas.munoz@intel.com>; Whaley, Graham <graham.whaley@intel.com>; kata-dev < kata-dev@lists.katacontainers.io> *Subject:* Re: [kata-dev] 答复: should github reset ack count on PR change?
I like the pull-approve behavior (no reset) more...
On Wed, Feb 13, 2019 at 9:34 AM zhangwei (CR) <zhangwei555@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@intel.com] 发送时间: 2019年2月13日 4:36 收件人: Whaley, Graham <graham.whaley@intel.com>; kata-dev < kata-dev@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@intel.com] Sent: Tuesday, February 12, 2019 11:59 AM To: kata-dev <kata-dev@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@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
--
--
Xu Wang
CTO & Cofounder, Hyper
github/twitter/wechat: @gnawux
Hyper_: Make VM run like container
--------------------------------------------------------------------- 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@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- James --- https://katacontainers.io/ | https://github.com/kata-containers <https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
Let's talk about this during the AC meeting :) Thanks, Sebastien ________________________________ From: Hunt, James O [james.o.hunt@intel.com] Sent: Tuesday, February 19, 2019 12:36 AM To: Whaley, Graham Cc: kata-dev Subject: Re: [kata-dev] 答复: should github reset ack count on PR change? Having lived with this for a while now, I've decided I'm with Xu - I don't like the current behaviour: it's confusing ("wait, didn't I ack that PR yesterday?") and information is being lost (the ack history). I think there is value in others being able to see that a PR *was* ack'd, even if it's subsequently been updated. It's also clear to all which set of people could/should be pinged for a fresh ack as github shows the timeline of events clearly on the PR. Cheers, James Le mer. 13 févr. 2019 à 10:45, Whaley, Graham <graham.whaley@intel.com<mailto:graham.whaley@intel.com>> a écrit : Vote so far is 2 for reset, and 1 for leave-alone… I will leave it on ‘reset on PR change’ right now, and we will see how it works out. Thanks for the replies! From: Xu Wang [mailto:xu@hyper.sh<mailto:xu@hyper.sh>] Sent: Wednesday, February 13, 2019 6:47 AM To: zhangwei (CR) <zhangwei555@huawei.com<mailto:zhangwei555@huawei.com>> Cc: Venegas Munoz, Jose Carlos <jose.carlos.venegas.munoz@intel.com<mailto:jose.carlos.venegas.munoz@intel.com>>; Whaley, Graham <graham.whaley@intel.com<mailto:graham.whaley@intel.com>>; kata-dev <kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io>> Subject: Re: [kata-dev] 答复: should github reset ack count on PR change? I like the pull-approve behavior (no reset) more... On Wed, Feb 13, 2019 at 9:34 AM zhangwei (CR) <zhangwei555@huawei.com<mailto:zhangwei555@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@intel.com<mailto:jose.carlos.venegas.munoz@intel.com>] 发送时间: 2019年2月13日 4:36 收件人: Whaley, Graham <graham.whaley@intel.com<mailto:graham.whaley@intel.com>>; kata-dev <kata-dev@lists.katacontainers.io<mailto:kata-dev@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@intel.com<mailto:graham.whaley@intel.com>] Sent: Tuesday, February 12, 2019 11:59 AM To: kata-dev <kata-dev@lists.katacontainers.io<mailto:kata-dev@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@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@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<http://hyper.sh/> Hyper_: Make VM run like container --------------------------------------------------------------------- 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@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev -- James --- https://katacontainers.io/ | https://github.com/kata-containers<https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
I tend to agree, James. Eric On Feb 19, 2019, at 6:37 AM, Boeuf, Sebastien <sebastien.boeuf@intel.com<mailto:sebastien.boeuf@intel.com>> wrote: Let's talk about this during the AC meeting :) Thanks, Sebastien ________________________________ From: Hunt, James O [james.o.hunt@intel.com<mailto:james.o.hunt@intel.com>] Sent: Tuesday, February 19, 2019 12:36 AM To: Whaley, Graham Cc: kata-dev Subject: Re: [kata-dev] 答复: should github reset ack count on PR change? Having lived with this for a while now, I've decided I'm with Xu - I don't like the current behaviour: it's confusing ("wait, didn't I ack that PR yesterday?") and information is being lost (the ack history). I think there is value in others being able to see that a PR *was* ack'd, even if it's subsequently been updated. It's also clear to all which set of people could/should be pinged for a fresh ack as github shows the timeline of events clearly on the PR. Cheers, James Le mer. 13 févr. 2019 à 10:45, Whaley, Graham <graham.whaley@intel.com<mailto:graham.whaley@intel.com>> a écrit : Vote so far is 2 for reset, and 1 for leave-alone… I will leave it on ‘reset on PR change’ right now, and we will see how it works out. Thanks for the replies! From: Xu Wang [mailto:xu@hyper.sh<mailto:xu@hyper.sh>] Sent: Wednesday, February 13, 2019 6:47 AM To: zhangwei (CR) <zhangwei555@huawei.com<mailto:zhangwei555@huawei.com>> Cc: Venegas Munoz, Jose Carlos <jose.carlos.venegas.munoz@intel.com<mailto:jose.carlos.venegas.munoz@intel.com>>; Whaley, Graham <graham.whaley@intel.com<mailto:graham.whaley@intel.com>>; kata-dev <kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io>> Subject: Re: [kata-dev] 答复: should github reset ack count on PR change? I like the pull-approve behavior (no reset) more... On Wed, Feb 13, 2019 at 9:34 AM zhangwei (CR) <zhangwei555@huawei.com<mailto:zhangwei555@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@intel.com<mailto:jose.carlos.venegas.munoz@intel.com>] 发送时间: 2019年2月13日 4:36 收件人: Whaley, Graham <graham.whaley@intel.com<mailto:graham.whaley@intel.com>>; kata-dev <kata-dev@lists.katacontainers.io<mailto:kata-dev@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@intel.com<mailto:graham.whaley@intel.com>] Sent: Tuesday, February 12, 2019 11:59 AM To: kata-dev <kata-dev@lists.katacontainers.io<mailto:kata-dev@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@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@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<http://hyper.sh/> Hyper_: Make VM run like container --------------------------------------------------------------------- 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@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev -- James --- https://katacontainers.io/ | https://github.com/kata-containers<https://github.com/clearcontainers> Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
participants (7)
-
Boeuf, Sebastien
-
Ernst, Eric
-
Hunt, James O
-
Venegas Munoz, Jose Carlos
-
Whaley, Graham
-
Xu Wang
-
zhangwei (CR)