Hi Kata-folk, In addition to GitHub, Kata development relies on an external service, PullApprove, in order to process PRs. This external service used to be free-as-in-beer, but they recently decided[1] to change their terms of service so that if "people who work on the repository get paid to do so, then we need to get paid too". They are planning to flip the switch on February 1, 2019. Our read of their unclearly-specified conditions to apply for a free plan concludes that we almost certainly would not qualify: despite the project being open source and run by a non-profit Foundation, most of the "people who work on the repository" get paid to do so. We could of course comply with their reasonably-priced new terms (and wait for the next bait-and-switch), but as an open source development best practice it is generally better to reduce our dependency on such external services, to avoid having the project be negatively affected by the decisions of a third-party service provider. Which is why I'm raising this thread, to tap the collective Kata mind for solutions. In order of decreasing preference, we would find an alternative solution that would 1- be open source, so that we could actually not depend on an additional external service provider, or at least have the option to switch to running it ourselves in case of sudden ToS changes 2- use built-in features of an external service we are already depending on (GitHub) 3- use a free-as-in-beer external service provider that has already published clear conditions for open source projects or projects run by non-profit Foundations Thoughts ? [1] https://medium.com/dropseed/changes-to-our-free-plans-2660423c3f6 -- Thierry Carrez (ttx)
Hi Thierry, Thanks for raising this issue. What are the options out there? I've found lgtmco (https://github.com/lgtmco/lgtm) but the repo has been archived which means we cannot expect any support. But this might be enough for our needs. Thanks, Sebastien On Tue, 2019-01-08 at 13:36 +0100, Thierry Carrez wrote:
Hi Kata-folk,
In addition to GitHub, Kata development relies on an external service, PullApprove, in order to process PRs. This external service used to be free-as-in-beer, but they recently decided[1] to change their terms of service so that if "people who work on the repository get paid to do so, then we need to get paid too". They are planning to flip the switch on February 1, 2019.
Our read of their unclearly-specified conditions to apply for a free plan concludes that we almost certainly would not qualify: despite the project being open source and run by a non-profit Foundation, most of the "people who work on the repository" get paid to do so.
We could of course comply with their reasonably-priced new terms (and wait for the next bait-and-switch), but as an open source development best practice it is generally better to reduce our dependency on such external services, to avoid having the project be negatively affected by the decisions of a third-party service provider.
Which is why I'm raising this thread, to tap the collective Kata mind for solutions. In order of decreasing preference, we would find an alternative solution that would
1- be open source, so that we could actually not depend on an additional external service provider, or at least have the option to switch to running it ourselves in case of sudden ToS changes
2- use built-in features of an external service we are already depending on (GitHub)
3- use a free-as-in-beer external service provider that has already published clear conditions for open source projects or projects run by non-profit Foundations
Thoughts ?
[1] https://medium.com/dropseed/changes-to-our-free-plans-2660423c3f6
Hi, I think a combination of probot's apps would do the job. On just a quick look, leads me to the following apps : 1. To enforce min no of approvals : https://probot.github.io/apps/minimum-reviews/ 2. To enforce DCO : https://probot.github.io/apps/dco/ 3. To auto assign PR's : https://probot.github.io/apps/auto-assign/ 4. For reminders : https://probot.github.io/apps/reminders/ There are a lot of other apps which can potentially make the contributor experience better. The apps listed there already run somewhere but if we need, we can run it on own servers and they should do fine. Plus, if these are not enough, we can create our own custom apps. We will need to deploy the custom one on our own though. So wdyt? On Tue, Jan 8, 2019 at 6:41 PM Boeuf, Sebastien <sebastien.boeuf@intel.com> wrote:
Hi Thierry,
Thanks for raising this issue. What are the options out there?
I've found lgtmco (https://github.com/lgtmco/lgtm) but the repo has been archived which means we cannot expect any support. But this might be enough for our needs.
Thanks, Sebastien
On Tue, 2019-01-08 at 13:36 +0100, Thierry Carrez wrote:
Hi Kata-folk,
In addition to GitHub, Kata development relies on an external service, PullApprove, in order to process PRs. This external service used to be free-as-in-beer, but they recently decided[1] to change their terms of service so that if "people who work on the repository get paid to do so, then we need to get paid too". They are planning to flip the switch on February 1, 2019.
Our read of their unclearly-specified conditions to apply for a free plan concludes that we almost certainly would not qualify: despite the project being open source and run by a non-profit Foundation, most of the "people who work on the repository" get paid to do so.
We could of course comply with their reasonably-priced new terms (and wait for the next bait-and-switch), but as an open source development best practice it is generally better to reduce our dependency on such external services, to avoid having the project be negatively affected by the decisions of a third-party service provider.
Which is why I'm raising this thread, to tap the collective Kata mind for solutions. In order of decreasing preference, we would find an alternative solution that would
1- be open source, so that we could actually not depend on an additional external service provider, or at least have the option to switch to running it ourselves in case of sudden ToS changes
2- use built-in features of an external service we are already depending on (GitHub)
3- use a free-as-in-beer external service provider that has already published clear conditions for open source projects or projects run by non-profit Foundations
Thoughts ?
[1] https://medium.com/dropseed/changes-to-our-free-plans-2660423c3f6
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Thanks Yash D Jain Github : @ydjainopensource <https://github.com/ydjainopensource> Twitter : @Yash_D_Jain <https://twitter.com/Yash_D_Jain> LinkedIn : in/yash-d-jain <https://www.linkedin.com/in/yash-d-jain/>
I’ve just open and Issue https://github.com/kata-containers/ci/issues/98 Which references a wiki page where I listed our current use cases and started to collect alternatives and their functionality: https://github.com/kata-containers/community/wiki/PullApproveAlternatives Whilst doing that I looked slightly deeper at probot, and indeed it does look like it has a number of features we would want to use. I’ve not looked into how it is configured/deployed – but presuming it needs a 24/7 machine, I’m sure we could either find one in our current CI system or discuss with the OSF infra folks deployment options. At a slightly higher level, in my mind I wonder if this is a feature that more OSF infra projects may like/require beyond just being used by Kata – and maybe that will swing where it is deployed and managed. Graham From: yash jain [mailto:ydjainopensource@gmail.com] Sent: Tuesday, January 8, 2019 3:48 PM To: Boeuf, Sebastien <sebastien.boeuf@intel.com> Cc: kata-dev@lists.katacontainers.io Subject: Re: [kata-dev] PullApprove future Hi, I think a combination of probot's apps would do the job. On just a quick look, leads me to the following apps : 1. To enforce min no of approvals : https://probot.github.io/apps/minimum-reviews/ 2. To enforce DCO : https://probot.github.io/apps/dco/ 3. To auto assign PR's : https://probot.github.io/apps/auto-assign/ 4. For reminders : https://probot.github.io/apps/reminders/ There are a lot of other apps which can potentially make the contributor experience better. The apps listed there already run somewhere but if we need, we can run it on own servers and they should do fine. Plus, if these are not enough, we can create our own custom apps. We will need to deploy the custom one on our own though. So wdyt? On Tue, Jan 8, 2019 at 6:41 PM Boeuf, Sebastien <sebastien.boeuf@intel.com<mailto:sebastien.boeuf@intel.com>> wrote: Hi Thierry, Thanks for raising this issue. What are the options out there? I've found lgtmco (https://github.com/lgtmco/lgtm) but the repo has been archived which means we cannot expect any support. But this might be enough for our needs. Thanks, Sebastien On Tue, 2019-01-08 at 13:36 +0100, Thierry Carrez wrote:
Hi Kata-folk,
In addition to GitHub, Kata development relies on an external service, PullApprove, in order to process PRs. This external service used to be free-as-in-beer, but they recently decided[1] to change their terms of service so that if "people who work on the repository get paid to do so, then we need to get paid too". They are planning to flip the switch on February 1, 2019.
Our read of their unclearly-specified conditions to apply for a free plan concludes that we almost certainly would not qualify: despite the project being open source and run by a non-profit Foundation, most of the "people who work on the repository" get paid to do so.
We could of course comply with their reasonably-priced new terms (and wait for the next bait-and-switch), but as an open source development best practice it is generally better to reduce our dependency on such external services, to avoid having the project be negatively affected by the decisions of a third-party service provider.
Which is why I'm raising this thread, to tap the collective Kata mind for solutions. In order of decreasing preference, we would find an alternative solution that would
1- be open source, so that we could actually not depend on an additional external service provider, or at least have the option to switch to running it ourselves in case of sudden ToS changes
2- use built-in features of an external service we are already depending on (GitHub)
3- use a free-as-in-beer external service provider that has already published clear conditions for open source projects or projects run by non-profit Foundations
Thoughts ?
[1] https://medium.com/dropseed/changes-to-our-free-plans-2660423c3f6
_______________________________________________ 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 -- Thanks Yash D Jain Github : @ydjainopensource<https://github.com/ydjainopensource> Twitter : @Yash_D_Jain<https://twitter.com/Yash_D_Jain> LinkedIn : in/yash-d-jain<https://www.linkedin.com/in/yash-d-jain/> --------------------------------------------------------------------- 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.
On 2019-01-08 16:27:29 +0000 (+0000), Whaley, Graham wrote: [...]
Whilst doing that I looked slightly deeper at probot, and indeed it does look like it has a number of features we would want to use. I’ve not looked into how it is configured/deployed – but presuming it needs a 24/7 machine, I’m sure we could either find one in our current CI system or discuss with the OSF infra folks deployment options.
At a slightly higher level, in my mind I wonder if this is a feature that more OSF infra projects may like/require beyond just being used by Kata – and maybe that will swing where it is deployed and managed. [...]
This is in fact a wildly popular feature of Zuul already for other OSF projects. You might even say it's Zuul's defining feature (the ability to interface with code review systems and merge changes triggered by specific events and defined sets of conditions). Probot sounds entirely redundant for the OpenDev infrastructure, and I can't imagine investing time in running more than one "pull request approver" engine, but I certainly don't speak for the rest of the OpenDev infra team. Probot also looks like it's GitHub-only, and all other OSF projects besides Kata are using an open code review system (Gerrit). Keep in mind that what's happening today with PullApprove could happen tomorrow with GitHub. Free software needs free tools. </soapbox> -- Jeremy Stanley
-----Original Message----- From: Jeremy Stanley [mailto:fungi@yuggoth.org] Sent: Tuesday, January 8, 2019 4:42 PM To: kata-dev@lists.katacontainers.io Subject: Re: [kata-dev] PullApprove future
On 2019-01-08 16:27:29 +0000 (+0000), Whaley, Graham wrote: [...]
Whilst doing that I looked slightly deeper at probot, and indeed it does look like it has a number of features we would want to use. I’ve not looked into how it is configured/deployed – but presuming it needs a 24/7 machine, I’m sure we could either find one in our current CI system or discuss with the OSF infra folks deployment options.
At a slightly higher level, in my mind I wonder if this is a feature that more OSF infra projects may like/require beyond just being used by Kata – and maybe that will swing where it is deployed and managed. [...]
This is in fact a wildly popular feature of Zuul already for other OSF projects. You might even say it's Zuul's defining feature (the ability to interface with code review systems and merge changes triggered by specific events and defined sets of conditions). Probot sounds entirely redundant for the OpenDev infrastructure, and I can't imagine investing time in running more than one "pull request approver" engine, but I certainly don't speak for the rest of the OpenDev infra team.
Probot also looks like it's GitHub-only, and all other OSF projects besides Kata are using an open code review system (Gerrit). Keep in mind that what's happening today with PullApprove could happen tomorrow with GitHub. Free software needs free tools. </soapbox> -- Jeremy Stanley
Thanks Jeremy - do you have a quick link to the Zuul features and configuration, such as checking For signed off by's, keyword matching for merge blocking, gathering ack's before merge etc.? Right now for kata, all this would have to work seamlessly through github, as that is really the core goto place for the kata workflow. I can then add Zuul to the wiki page as an option. Thanks, 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.
On 2019-01-08 16:56:32 +0000 (+0000), Whaley, Graham wrote: [...]
Thanks Jeremy - do you have a quick link to the Zuul features and configuration, such as checking For signed off by's, keyword matching for merge blocking, gathering ack's before merge etc.? Right now for kata, all this would have to work seamlessly through github, as that is really the core goto place for the kata workflow. I can then add Zuul to the wiki page as an option.
The current pipeline triggers available for Zuul's GitHub connection driver are documented at https://zuul-ci.org/docs/zuul/admin/drivers/github.html#trigger-configuratio... and the rest of the things you mentioned (validating commit messages, checking earlier PR comment contents) could likely be performed as lightweight (node-less) jobs run from one or more of those trigger events. I'll be the first to admit I have basically zero experience with GitHub-centric code review workflows, but I'll ask people in the Zuul community who use it in conjunction with GitHub whether they have any suggestions for checking some of those conditions you mentioned (particularly the "keyword matching for merge blocking" and "gathering ack's before merge"). -- Jeremy Stanley
On 2019-01-08 17:16:44 +0000 (+0000), Jeremy Stanley wrote: [...]
The current pipeline triggers available for Zuul's GitHub connection driver are documented at https://zuul-ci.org/docs/zuul/admin/drivers/github.html#trigger-configuratio... and the rest of the things you mentioned (validating commit messages, checking earlier PR comment contents) could likely be performed as lightweight (node-less) jobs run from one or more of those trigger events.
I'll be the first to admit I have basically zero experience with GitHub-centric code review workflows, but I'll ask people in the Zuul community who use it in conjunction with GitHub whether they have any suggestions for checking some of those conditions you mentioned (particularly the "keyword matching for merge blocking" and "gathering ack's before merge").
To follow up, it appears organizations using Zuul in combination with GitHub (standard or private Enterprise) are relying on maintainers with "committer" access applying "labels" to trigger merging of pull requests. There were also recommendations for branch protection with required status, and setting a "codeowners" file with required reviews for more fine-grained control. An example job definition was shared for verifying that all pull request commit messages include a signed-off-by footer too, on which the Ansible AWX project is currently relying (sounds like it may wind up in the Zuul standard library in the near future even). You can see the brief conversation at: http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2019-01-08.log.html#t... Hope that helps! -- Jeremy Stanley
participants (5)
-
Boeuf, Sebastien
-
Jeremy Stanley
-
Thierry Carrez
-
Whaley, Graham
-
yash jain