Grant try and perf access to gsoc-contributors

[joshtriplett]

Contributors may potentially work on performance, or on other things
that benefit from try access. We trust gsoc-contributors to not abuse
this access.

[jackh726]

Current policy is to not be granting people individual permissions, but rather grant permissions through teams.

[joshtriplett]

@jackh726 I wasn't aware of that policy.

I wonder how reasonable it would be to grant try and perf to gsoc-contributors? We already grant dev-desktop to that team.

[jackh726]

That I'm in favor of.

cc @Kobzol, not sure who else is a great ping here since I don't think it'll be a controversial decision

[Kobzol]

I guess that we will turn the past gsoc-contributors into alumni once GSoC 2025 starts (but maybe Fractal will do GSoC with us again, who knows 😆), so that wouldn't work, I think.

I probably wouldn't tie this together with gsoc-contributors. But at the same time, I don't know of a different team for this :( We don't really have a good story for these situations at the moment.

[jackh726]

I am okay with saying that gsoc-contributors contains both current and past but still active (on the project) gsoc contributors - this way contributors have the same support to continue working on their project even past the end of the gsoc period. Of course, we could qualify this with some sort of criteria for moving to alumni (maybe we require that the mentor still is "+1" on the project).

[Kobzol]

That's a good idea! Ok, let's do it that way.

[jackh726]

That said: not sure if the work @FractalFir has been doing on rust-lang/rust is related to the .NET/C backend at all, so not sure if it even makes sense in this situation to tie the two decisions

[joshtriplett]

It seems like a reasonable interim step. It will not surprise me even a little bit if FractalFir ends up on another team in the future. :)

[jackh726]

@joshtriplett if you edit the PR to put these perms on the team, I'll merge

[FractalFir]

That said: not sure if the work @FractalFir has been doing on rust-lang/rust is related to the .NET/C backend at all, so if it even makes sense in this situation to tie the two decisions

To chip in for a moment: The primary reason I looked at MIR optimization is that they benefit my project. For example, both .NET and some smaller C compilers have trouble optimizing Rust iterators.

Additionally, I have hit some performance bootlenecks caused by the amount of generated C. For example, rustc transplies to ~2.1 GB of C. That causes most C compilers to slow down to a crawl.

Since optimizations that reduce the amount of generated C also tend to reduce the amount of generated LLVM-IR, I am kind of killing two birds with one stone. Optimizations in rustc also tend to have more eyes on them(compared to my project), which means it is much harder for a subtle bug to sneak in.

[joshtriplett]

@joshtriplett if you edit the PR to put these perms on the team, I'll merge

Done.