skip
/
SIG-FastTrack
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Initial write-up of SIG guidelines and details 

-Skip
This commit is contained in:
Skip Grube 2023-08-05 14:36:53 -04:00
commit cee74c8a91
1 changed files with 69 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
README.md Normal file
View File

@ -0,0 +1,69 @@
# Rocky Linux SIG/FastTrack
SIG-FastTrack is a place for new packages and enhancements/upgrades to existing Rocky packages. To end-users, it will be 2 "no warranty, you break it you buy it" repositories that can be enabled to enhance their Rocky Linux installs with new and updated packages. This is a great way to provide optional much-needed functionality for Rocky users, while not interfering with the core distro's compatibility promises.
## Contribution Guidelines
Philosophically, this SIG should be wide open to contributions, with much less rigor or vetting than something like EPEL. Newer versions of existing Rocky Linux packages, as well as brand new packages are both welcome. The philosophy of this SIG is: **We don't need reasons to add a contribution, we need reasons to *not* add it**.
Having said that, we can't have absolute anarchy. There must be some kind of a guideline to what can and cannot be accepted.
### Possible Reasons a Package Cannot be Added to FastTrack:
- **It breaks or conflicts with the existing Rocky Repositories**. The FastTrack repos may provide RHEL-incompatible packages and updates, but they should never break DNF. If a user gets dependency or other DNF errors by running `dnf update` or `dnf install` , then the FastTrack package must be pulled or fixed.
- **It changes a "core functionality" package in a questionable way, especially security-related.** The definition of "core" package here is a judgment call made by SIG leadership. These are things like OpenSSL, OpenSSH, nss, glibc, rpm, etc. We don't want to put users at risk by warping the way their Rocky system works and introducing issues. It may be possible to work around this by introducing an *additional* non-conflicting package version.
**Example:** if you're interested in packaging openssl-3.0.7 to Rocky 8, you wouldn't simply override the base openssl-1.1.1k which everything depends on. Instead, you might create a separate compatible package, "openssl-compat-307", which contains the newer library without conflicting with any files or library paths in the default openssl.
- **It introduces a severe security risk**. This is again a judgment call made by the SIG as a whole. Generally this refers to extreme, remotely-exploitable security issues, usually 9.8 - 10 on the CVE/CVSS scale. If your package installs a listening daemon that is activated and allows remote commands without authentication, for example, that would be a clear reason not to have it available.
- **It already exists in EPEL, RPMFusion, or another common 3rd-party repo**. The intention of this SIG is to provide as much "new and cool" stuff to Rocky Linux users as possible. If people can already get software from one of the popular 3rd-party repos, that's probably the best place to go. Something we'd like to see as this SIG progresses is to use the initial work done here and add it to one of these more established repositories.
- **It clearly belongs in another SIG**. The goal of this SIG is to be a "catchall" for new or enhanced Enterprise Linux packages. However, many times a package clearly doesn't belong in FastTrack, but in another SIG already set up around that package's area. Enhanced kernels should probably go in SIG/Kernel, embedded or single-board specific packages should go in SIG/AltArch, etc.
Outside of these listed areas, if someone puts in the effort to build and test a package against Rocky Linux, and it helps users in some way, it is welcome to be included in this SIG.
<br />
## Submitting New Packages
To fill in.
TLDR: open an issue in https://git.resf.org/sig_fasttrack/meta/issues
Always great to talk about things, plans, challenges, etc. in https://chat.rockylinux.org/rocky-linux/channels/sig-fasttrack
<br />
## Git Storage and Branching
To fill in
TLDR:
- Packages stored in: https://git.rockylinux.org/sig/fasttrack/src/PKG
- Wiki/docs/OtherInfo stored in: https://git.resf.org/sig_fasttrack/* (should we just throw it all in git.rockylinux.org?)
- https://git.rockylinux.org/sig/fasttrack/{rpms,patch} also exist. Peridot imports src/PKG --> rpms/PKG
- Peridot will be doing package builds and publish, in accordance with other SIGs
- Maintainers should have commit control over git.rockylinux.org/sig/fasttrack/src/PKG/ . And be able to take merge requests, add new versions, etc.
- Fedora packaging guidelines followed as close as is practical. With the understanding that much of the Rocky community is still learning packaging best practices, and nothing is perfect first try. Iterative package improvements will happen as our community gains more experience.
<br />
## Pull Requests
Pull requests are always welcome against package sources (git.rockylinux.org/sig/fasttrack/src/PKG/ ). It's up to maintainer(s) or SIG admins to accept/deny requests and maintain quality.
Pull requests should never violate the guidelines listed above (like introduce a massive security hole, or conflict with stock Rocky Linux packages).
<br />
## Builds
Builds done in Peridot, can test locally in Mock, against BaseOS+AppStream+CRB+Devel. Mock configs matching what is done in Peridot should be provided, so contributors can easily develop/test.
**Big question**: 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.
Would imply `sig-fasttrack-release` package depending on `epel-release`