Scope gpu01 access to ai-packagers-sig and open up ai-ml-sig membership #34

Open
opened 2026-07-11 02:31:18 +00:00 by jflory7 · 5 comments
Owner

Summary

Separate infrastructure access (specifically the gpu01 host) from general SIG membership by scoping it to the ai-packagers-sig FAS group instead of ai-ml-sig.

Background

Membership in the ai-ml-sig FAS group currently grants access to shared infrastructure, including the gpu01 host, which has attracted a lot of attention. That ties together two different things — community participation and hardware access. Anyone who wants to follow along with the SIG or contribute to documentation, skills, or governance shouldn’t need to be in a group that also grants hardware access.

This proposal separates those concerns: keep ai-ml-sig as the broad community group — open to anyone interested — and scope infrastructure access to ai-packagers-sig, which is already focused on packaging and CI work.

I’m putting this forward for SIG review and a vote. If the SIG approves, I’ll execute the changes below.

Details

  • Scope gpu01 host access to ai-packagers-sig FAS group membership instead of ai-ml-sig.
  • Update ai-ml-sig FAS group description to reflect that it is the community/discussion group — open to anyone interested in the SIG.
  • Update ai-packagers-sig FAS group description to reflect that it manages access to packaging infrastructure and shared hardware.
  • Document the distinction in the newcomer guide (see #29).

Outcome

SIG membership is clearly separated from infrastructure access, making it easier to welcome new contributors without conflating participation with hardware privileges.

Assisted-by: Claude Opus 4.6 (1M context)

### Summary Separate infrastructure access (specifically the `gpu01` host) from general SIG membership by scoping it to the `ai-packagers-sig` FAS group instead of `ai-ml-sig`. ### Background Membership in the `ai-ml-sig` FAS group currently grants access to shared infrastructure, including the `gpu01` host, which has attracted a lot of attention. That ties together two different things — community participation and hardware access. Anyone who wants to follow along with the SIG or contribute to documentation, skills, or governance shouldn’t need to be in a group that also grants hardware access. This proposal separates those concerns: keep `ai-ml-sig` as the broad community group — open to anyone interested — and scope infrastructure access to `ai-packagers-sig`, which is already focused on packaging and CI work. I’m putting this forward for SIG review and a vote. If the SIG approves, I’ll execute the changes below. ### Details - [ ] Scope `gpu01` host access to `ai-packagers-sig` FAS group membership instead of `ai-ml-sig`. - [ ] Update `ai-ml-sig` FAS group description to reflect that it is the community/discussion group — open to anyone interested in the SIG. - [ ] Update `ai-packagers-sig` FAS group description to reflect that it manages access to packaging infrastructure and shared hardware. - [ ] Document the distinction in the newcomer guide (see #29). ### Outcome SIG membership is clearly separated from infrastructure access, making it easier to welcome new contributors without conflating participation with hardware privileges. <sub>_Assisted-by: Claude Opus 4.6 (1M context)_</sub>
jflory7 self-assigned this 2026-07-11 02:31:18 +00:00
jflory7 changed title from Propose a newcomer guide for the AI/ML SIG to Scope gpu01 access to ai-packagers-sig and open up ai-ml-sig membership 2026-07-11 02:38:40 +00:00
Owner

I think it is too early to discuss the use.

I think it is too early to discuss the use.
Owner

@trix wrote in #34 (comment):

I think it is too early to discuss the use.

I agree. There are still too many things in progress to be able to make decisions around any of the GPU machines. I'm not saying that we can't do anything just that anything we figure out would be temporary, at best

@trix wrote in https://forge.fedoraproject.org/ai-ml/tickets/issues/34#issuecomment-1063202: > I think it is too early to discuss the use. I agree. There are still too many things in progress to be able to make decisions around any of the GPU machines. I'm not saying that we can't do anything just that anything we figure out would be temporary, at best
Owner

Also, I want to make sure that infra is involved with any of these decisions. Are there any safeguards or checks in place to at least detect improper usage? It's not like there haven't been checkout-able systems managed by infra in the past but I don't remember much about them or how they were configured

Also, I want to make sure that infra is involved with any of these decisions. Are there any safeguards or checks in place to at least detect improper usage? It's not like there haven't been checkout-able systems managed by infra in the past but I don't remember much about them or how they were configured
jflory7 added the due date 2026-08-13 2026-07-16 19:34:47 +00:00
Author
Owner

Discussed in 2026-07-16 Fedora AI/ML SIG meeting.


@jflory7 flagged the significantly rewritten ticket for feedback. @tflink and @trix both said it is too early to formalize access decisions given the number of moving parts around hardware procurement and ownership. @gordonmessmer noted that an Acceptable Use Policy is needed regardless of access mechanism, since "CI" describes a mechanism, not a purpose. @tflink mentioned that Fedora Infrastructure has managed packager-checkout-able systems for exotic hardware in the past, so precedent exists.

  • Agreed: In the short-term, as far as existing/available GPU infrastructure is concerned, the immediate focus for the available hardware is for CI purposes in the F45 release cycle. We commit to following up on the August 13th SIG meeting if there is no new clarity to the hardware access to write something officially. For now, we agree for any requests that come up in the meantime, we will close as wontfix, explaining that the GPU hardware is in a "transitionary/exploration" phase while we discover what acceptable use looks like for the Fedora community.
  • Action: @jflory7 to open a new ticket for Acceptable Use Policy discussion, likely targeting Q4.
  • Follow-up date: August 13, 2026 SIG meeting.

Assisted-by: Claude Opus 4.6 (1M context)

_Discussed in [2026-07-16 Fedora AI/ML SIG meeting](https://discussion.fedoraproject.org/t/fedora-ai-ml-sig-meeting-2026-07-16-skills-reviewers-team-approved-help-wanted-with-llama-cpp-and-navigating-gpu-infrastructure/196876)._ --- @jflory7 flagged the significantly rewritten ticket for feedback. @tflink and @trix both said it is too early to formalize access decisions given the number of moving parts around hardware procurement and ownership. @gordonmessmer noted that an Acceptable Use Policy is needed regardless of access mechanism, since "CI" describes a mechanism, not a purpose. @tflink mentioned that Fedora Infrastructure has managed packager-checkout-able systems for exotic hardware in the past, so precedent exists. - **Agreed:** In the short-term, as far as existing/available GPU infrastructure is concerned, the immediate focus for the available hardware is for CI purposes in the F45 release cycle. We commit to following up on the August 13th SIG meeting if there is no new clarity to the hardware access to write something officially. For now, we agree for any requests that come up in the meantime, we will close as `wontfix`, explaining that the GPU hardware is in a "transitionary/exploration" phase while we discover what acceptable use looks like for the Fedora community. - **Action:** @jflory7 to open a new ticket for Acceptable Use Policy discussion, likely targeting Q4. - **Follow-up date:** August 13, 2026 SIG meeting. <sub>_Assisted-by: Claude Opus 4.6 (1M context)_</sub>
Author
Owner

@tflink wrote in #34 (comment):

Also, I want to make sure that infra is involved with any of these decisions. Are there any safeguards or checks in place to at least detect improper usage?

When I open this new ticket soon for us to discuss it, I don't think there is any way we could be successful without working with Fedora Infrastructure on this. I'll make it clear beyond our own initial discussions and ideas that we need to put something together to present to Infrastructure.

@tflink wrote in https://forge.fedoraproject.org/ai-ml/tickets/issues/34#issuecomment-1063214: > Also, I want to make sure that infra is involved with any of these decisions. Are there any safeguards or checks in place to at least detect improper usage? When I open this new ticket soon for us to discuss it, I don't think there is any way we could be successful without working with Fedora Infrastructure on this. I'll make it clear beyond our own initial discussions and ideas that we need to put something together to present to Infrastructure.
Sign in to join this conversation.
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

2026-08-13

Dependencies

No dependencies set.

Reference
ai-ml/tickets#34
No description provided.