Taken to Governing Board for endorsement, not strictly necessary by charter, but helps with resource deployment
Was received with enthusiasm and unanimous vote
Larry: sent invitations to various people for TSC membership, some have accepted, some are thinking it over / checking with their organizations. One very good offer from someone who wasn’t already on his list. Will report next week, hold first meeting.
Working on governing documents, mostly a repeat of OCIO, changing names as necessary, borrowing from other projects, but hopefully sticking to the script as much as possible to make it easy to graduate.
Google Summer of Code (Larry) [0:15-0:20]
Congrats on work done by Larry on GSOC.
Tiago joining us on this meeting as a GSCO student.
Larry: ASWF is a mentoring organization announced by Google, not clear how many paid positions will be announced, may be based on number of student applications. Have seen student activity on a couple of projects. Asking project leads about feedback?
Brian: 5 or 6 folks have reached out via email or GitHub, a couple of small PRs. Had to “tone down” the excitement a bit until the program actually starts.
Michael: several people joined slack, a PR submitted, interest in proposed tasks.
Cary: no one reached out to OpenEXR yet.
Aloys: one person reached out to Docker project. They didn’t really say they were part of GSOC program, was assuming they were. Question: do we have to get confirmation that they are “part of the program”? Larry: currently no one is “part of the program”, they will apply in a few weeks, and we will decide who we would want.
Daniel: enthusiasm and support at GSOC program from Governing Board, including other activities within the Academy, including any other activities that would involve students, for instance physical meetups.
Larry: want to encourage everybody if they know students, former interns to point them to our GSCO projects, recruiting is allowed and encouraged. Also the mentoring organization gets a small stipend per student, including some travel allowance to the Google GSOC in person conference at Google (Mountain View). Speakers are a “who’s who” of the open source world. Larry very enthusiastic about this event.
USD Working Group (Cory) [0:20-0:30]
Cory: have filled out proposed form by John. Haven’t created GitHub repo yet (coordinate with LF releng?).
Worded very broadly for now, not a lot of specific language. Encourage best practices, adoption at large in the community. First working group meeting to work on setting more specific goals.
Proposed times on when the meeting might take place, John will send out Doodle poll (see link) and will send out email to TAC list. Looking at people on the TAC to propose potential members.
Cory: aim is to support the adoption efforts through consolidation and sharing of best practices, and helping with issues raised in various USD support channels where possible
Not a steering committee: members on the WG will have the same influence on USD as already participating members in the USD community
JF: is there a need to try to leverage the ASWF CI infrastructure? Cory: could be a project, but not necessarily a goal. Would like to be doing CI in the open rather than internally using Jenkins, and having public binaries. Daniel: this should be an achievable goal given some of the infrastructure already in place.
Daniel: key part is that we engage constructively with USD team. Let’s move on to the next steps as proposed.
Python 3 Working Group (Josh) [0:30-0:35]
Daniel: Josh won’t have the bandwidth to take on this project, need to look at someone else, either in the TAC or outside
Had some back and forth with John in the WG template to reflect that the person leading a WG doesn’t have to be a member of the TAC
Is anyone in a position to volunteer themselves, or propose someone external? Can be discussed now or later / off meeting. There is still a lot of interest in leveraging the foundation to achieve this goal.
Project Repository Privileges (Dan) [0:35-0:45]
Has come up a few times in the context of repo setup
Address friction points, project TSE don’t have full access, they need higher level access. GitHub has now added a Maintainer level which offers most of the privileges of Administrator level.
Dan not on this call. Have TSC chairs looked at the PR? Does anyone have experience with the other levels of GitHub access control? Some ambiguity as to what some of these permission levels entail.
Kimball: no experience
Daniel: to be followed up with LF releng and Dan at the CI meeting, then take back to TAC meeting for a policy decision.
Potential damage limited by only being able to spin up a single GPU accelerated VM per account by default without raising limits (which requires interaction with CSP support).
Azure Pipelines only for now, need to look at GitHub Actions
Daniel: asking Sean whether this looks like it makes sense? Sean: can report offline, not too concerned about optimizing for cost.
Daniel: logical next step would be to take to LF releng team, would they be ready to take this on as supported infrastructure.
JT: Update on Linux Scale Expo in Pasadena next week, have some passes available
Updates on candidate projects
Varia:
Daniel: Should aim to solidify TAC goals for this year, will be shared on the mailing list