+1 I would like to suggest we make a requirement that the trusted user has 2F authentication <https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication> set to reduce the risk of hacking the account. I think by joining the triage group ASF verifies it so there are some benefits to it. If we decide against the triage group then I guess the sponsor should verify it(?)
On Tue, Feb 22, 2022 at 12:11 AM Vikram Koka <[email protected]> wrote: > +1 > > I really like the road to committership perspective on this as well! > I also like the suggestion of a periodic (ideally automated) clean up of > this list for inactive users and committers as well. > > > > On Fri, Feb 18, 2022 at 7:54 AM Jarek Potiuk <[email protected]> wrote: > >> +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? >> >
