Details
-
Wish
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
Airflow
Description
Per email from Daniel https://lists.apache.org/thread/g7bb70ymlmkzjlx1rpvq46dwz54qcpdb
I wanted to request an exemption for all Airflow projects from mandatory "always require approval for external contributors” setting of GitHub Actions.
There are few reasons:
We absolutely won't be able to cope with the increased burden we will have as committers. big time
I believe also our contributors numbers will likely drop significantly as result. Let me explain why.
Currently our CI is self-service, you iterate on it until it is green - applying literally few 100s of checks commiters would have to do manually otherwise. The reason we do it is to automate all the "automatable" feedback we can often BEFORE our attention is put to the detailed code.
The CI provides a feedback and allows outside contributor to iterate (sometimes multiple times) until the CI gets green without a single interaction from a commiter. If we require approval, we will delay such feedback loop enormously. This will increase the interaction between contributors and committers but only at the level of "ping! someone approve". We already have that happening with "first-time" contributors and it is already very annoying.
Not having the feedback would require a committer to take a look at the issue and its code and click "approve" for every single iteration.
In our case we are might look at a PR sometimes after a day or two after it gets green. If we will have the same for all "approves" of a run this means that such contributions that require quite a few iterations by weeks (sometimes we have 5-10 iterations).
As result most of our contributors will either give up, or start pinging the committers for every change which will increase amount of pretty useless, technical communication by an order od magnitude at least
I think also such policy will not increase the security in general for any other project. This is a red-herring IMHO and you should give up the idea completely.
When you will add a need to approve every single PR of every single external contributor with every single iteration, there is no way the code will be reviewed by the one who approves it every single time. What you will get is a false sense of security. In reality what you are asking for is to have committer to review every single iteration to look for potential security issues to approve. This is is humanly impossible to do. When you have 10 iterations for the same change to fix this or that CI issue, after nth time you will stop looking. This is how human brain works.
As result you will get everyone approving everything without looking. Not because they will neglect security, but because it will be impossible to do it differently.
I wanted to request an exemption for all Airflow projects from mandatory "always require approval for external contributors” setting of GitHub Actions.
There are few reasons:
We absolutely won't be able to cope with the increased burden we will have as committers. big time
I believe also our contributors numbers will likely drop significantly as result. Let me explain why.
Currently our CI is self-service, you iterate on it until it is green - applying literally few 100s of checks commiters would have to do manually otherwise. The reason we do it is to automate all the "automatable" feedback we can often BEFORE our attention is put to the detailed code.
The CI provides a feedback and allows outside contributor to iterate (sometimes multiple times) until the CI gets green without a single interaction from a commiter. If we require approval, we will delay such feedback loop enormously. This will increase the interaction between contributors and committers but only at the level of "ping! someone approve". We already have that happening with "first-time" contributors and it is already very annoying.
Not having the feedback would require a committer to take a look at the issue and its code and click "approve" for every single iteration.
In our case we are might look at a PR sometimes after a day or two after it gets green. If we will have the same for all "approves" of a run this means that such contributions that require quite a few iterations by weeks (sometimes we have 5-10 iterations).
As result most of our contributors will either give up, or start pinging the committers for every change which will increase amount of pretty useless, technical communication by an order od magnitude at least
I think also such policy will not increase the security in general for any other project. This is a red-herring IMHO and you should give up the idea completely.
When you will add a need to approve every single PR of every single external contributor with every single iteration, there is no way the code will be reviewed by the one who approves it every single time. What you will get is a false sense of security. In reality what you are asking for is to have committer to review every single iteration to look for potential security issues to approve. This is is humanly impossible to do. When you have 10 iterations for the same change to fix this or that CI issue, after nth time you will stop looking. This is how human brain works.
As result you will get everyone approving everything without looking. Not because they will neglect security, but because it will be impossible to do it differently.
Attachments
Attachments
Issue Links
- is related to
-
-
- Closed
-