+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? >
