+1. That will be a huge one and actually adds an interesting "path to committership" intermediate step. Being a committer (for code) is mostly the trust in the person that they can approve other's code. This will be "trust that they can run their code on our infrastructure".
The nice thing about it is all trackable as well - which is enough reason for no-one doing anything bad. And those permissions cannot really impact much more than mostly impacting results of other CI builds and potentially ab-using the power of our self-hosted machines (which is not worthy to abuse just this one single repo - it would only make sense if you find a mass way of abusing it). And if we trust people also because they are in a work relationship - this is quite a good "trust" reason, One thing that I would add - it could be great to add a periodic (automated ? ) cleanup of the list for inactive users (maybe even inactive committers in this case)? This will - in the long run - make the list more "accurate" and easier to maintain. Also There is this (unlikely) even when GitHub user changes the username, there is currently no good protection from someone actually "taking over" the github name, so keeping the list to only "recently active" might help with that a lot. J. On Fri, Feb 18, 2022 at 4:07 PM Ash Berlin-Taylor <[email protected]> wrote: > > Hi all, > > I'd like to propose we start allowing more users to use the self-hosted > runners -- they are much much quicker to run test workflows. And by making > promising people's tests run quicker hopefully we can encourage them to make > more PRs and continue on the path towards becoming a committer. > > Currently only committers and PMC members test builds are run using the > self-hosted runners, everyone else has to use the GitHub public runners. The > "stuck in queue" issue doesn't plague us much anymore (I think?), but the > main issue is still that the GitHub runners only have 8GB vs the 64GB of the > self-hosted (half of which is used as RAM FS) and as a result they are much, > much slower. > > So I propose that we "allow users we trust" to run on the self-hosted > runners. This is purposefully a lighter weight process than adding those > users to the Triage group (which we need to have a "vote"/mailing list for > and then ask ASF Infra team to make the changes to) and is essentially a way > to make the contributing process nicer for those that have shown interest and > promise. > > I am thinking that this would often be used for "this person is making a > number of good quality PRs, and is on the road to being a committer". > > In terms of project process, all I'm envisaging is that this requires a PR to > add someone's GitHub username to > https://github.com/apache/airflow/blob/366c66b8f6eddc0d22028ef494c62bb757bd8b8b/.github/workflows/ci.yml#L80-L123 > and then the "normal" review process to get the change merged. > > By adding a user to that list the committer/PMC member is saying "I am > sponsoring this user and trust them to not be malicious". > > There will be a bit more work to finish this off, namely we'll need to get > https://github.com/apache/airflow-ci-infra/pull/20 finished and working. > > We should probably be aware that if we do this it will likely be "people we > (committers) work with" in the first instance. Are we okay with that, even if > they haven't yet contributed (much/at all) to Airflow? > > Are there any other criteria that people thing we should apply before adding > users to this list? > > Thoughts?
