[SIG] Requests for SIG Proposal: FastTrack #11

Open
opened 2023-08-01 03:04:56 +00:00 by label · 5 comments
Owner

Introduction

Hello, I am Louis Abel, part of Release Engineering and SIG/Core. This request is part of a proposal brought to Mattermost by @neil, with comments from myself, @skip, and @tgo.

Initial Project

FastTrack, as an ode to a past CentOS repository of a similar name, is a SIG to attempt to provide the following:

  • Fixes, customizations, improvements to packages that the community would like to see
    • This also includes doing backports of patches that may not be released by our upstreams to address any type of bugs
  • Potential packages that could potentially make it to CentOS Stream or EPEL
  • Newer versions of software that override the base repositories that would likely never land in RHEL, CentOS Stream, or EPEL

There would be a few starting repositories: fasttrack-common, fasttrack-updatesandfasttrack-np` (for "new packages")

Initial Asks

Check your initial requests for this SIG. Defaults are filled in.

  • Groups in Rocky Account Services
  • RESF Git Service Organization
  • Channel in Mattermost
  • Mail List
  • Bridge Mattermost Channel to IRC and Matrix
  • Forums category section
  • Rocky Linux GitLab groups

Checklist

  • I have read the Special Interest Group Guide
  • I have put in the initial proposal at the appropriate venue (such as mattermost)
  • I acknowledge that I may be sponsoring this Special Interest Group
## Introduction Hello, I am Louis Abel, part of Release Engineering and SIG/Core. This request is part of a proposal brought to Mattermost by @neil, with comments from myself, @skip, and @tgo. ## Initial Project FastTrack, as an ode to a past CentOS repository of a similar name, is a SIG to attempt to provide the following: * Fixes, customizations, improvements to packages that the community would like to see * This also includes doing backports of patches that may not be released by our upstreams to address any type of bugs * Potential packages that could potentially make it to CentOS Stream or EPEL * Newer versions of software that override the base repositories that would likely never land in RHEL, CentOS Stream, or EPEL There would be a few starting repositories: `fasttrack-common, `fasttrack-updates` and `fasttrack-np` (for "new packages") ## Initial Asks Check your initial requests for this SIG. Defaults are filled in. - [x] Groups in Rocky Account Services - [x] RESF Git Service Organization - [x] Channel in Mattermost - [x] Mail List - [x] Bridge Mattermost Channel to IRC and Matrix - [x] Forums category section - [x] Rocky Linux GitLab groups ## Checklist - [x] I have read the [Special Interest Group Guide](https://wiki.rockylinux.org/special_interest_groups/sig_guide/) - [x] I have put in the initial proposal at the appropriate venue (such as mattermost) - [x] I acknowledge that I may be sponsoring this Special Interest Group
label added the
SIG_Proposal
label 2023-08-01 03:04:56 +00:00
Owner

I've taken the liberty of writing up some guidelines, details, and "vision" (loaded word), on what this might look like: https://git.resf.org/skip/SIG-FastTrack/src/branch/main/README.md

Very much a work in progress, please modify/correct/add-to as needed.

I think this might be the beginnings of a pages wiki for this SIG.

I've taken the liberty of writing up some guidelines, details, and "vision" (loaded word), on what this might look like: https://git.resf.org/skip/SIG-FastTrack/src/branch/main/README.md Very much a work in progress, please modify/correct/add-to as needed. I think this might be the beginnings of a pages wiki for this SIG.
Author
Owner

Do we want the SIG to be dependent on EPEL, and build against that as well? Potential huge benefit of allowing way more packages (EPEL has a lot of dependencies), but potential pitfall of stability

There should be very rarely a reason to depend on EPEL or any other third-party repository. This would require FastTrack to have EPEL enabled for some packages, which imo is not acceptable. There are no SIG's that should have dependency on EPEL (aka SIG's should be self sufficient and self reliant).

We've had this discussion before in multiple sig's, including sig core. It is always recommended to bring over deps from epel (or otherwise) to address deps and not be reliant on a third-party repository.

should we just throw it all in git.rockylinux.org?

No, this goes against the SIG guide that implies that package content goes to git.rockylinux.org and meta/wiki content exists in git.resf.org.

>Do we want the SIG to be dependent on EPEL, and build against that as well? Potential huge benefit of allowing way more packages (EPEL has a lot of dependencies), but potential pitfall of stability There should be very rarely a reason to depend on EPEL or any other third-party repository. This would require FastTrack to have EPEL enabled for some packages, which imo is not acceptable. There are no SIG's that should have dependency on EPEL (aka SIG's should be self sufficient and self reliant). We've had this discussion before in multiple sig's, including sig core. It is always recommended to bring over deps from epel (or otherwise) to address deps and not be reliant on a third-party repository. >should we just throw it all in git.rockylinux.org? No, this goes against the [SIG guide](https://wiki.rockylinux.org/special_interest_groups/sig_guide/content/#importing-to-the-resf-git-service) that implies that package content goes to git.rockylinux.org and meta/wiki content exists in git.resf.org.
Owner

Those both sound reasonable. We'll keep package content separate from meta/doc content, in-line with other SIGs.

And we'll make it a requirement that each package must build against BaseOS+AppStream+CRB+Devel+SIG-FastTrack repos. Duplicate EPEL/RPMFusion/etc packages can be brought in if they are dependencies on the journey to building a desired package.

I can update my little doc accordingly.

Those both sound reasonable. We'll keep package content separate from meta/doc content, in-line with other SIGs. And we'll make it a requirement that each package must build against BaseOS+AppStream+CRB+Devel+SIG-FastTrack repos. Duplicate EPEL/RPMFusion/etc packages can be brought in if they are dependencies on the journey to building a desired package. I can update my little doc accordingly.
Owner

Have updated the doc with clarifications. I'm hoping we can copy+paste pieces of content for the SIG wiki.

Have updated the doc with clarifications. I'm hoping we can copy+paste pieces of content for the SIG wiki.
Owner

Approved in rocky-linux/board#1

Approved in https://git.resf.org/rocky-linux/board/issues/1
Sign in to join this conversation.
No Milestone
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'.

No due date set.

Dependencies

No dependencies set.

Reference: sig_core/meta#11
No description provided.