This is the second draft. It has added a section in the developer section saying to clean your packages up when you are done playing and testing them. Edit's are still welcome, but I think it covers everything that has been discussed and approved. This will be published about the same time that - fedpkg doesn't require you to build playground when building epel -- https://pagure.io/fedpkg/issue/414 - package.cfg isn't automatically added to epel8 branches when they are created -- https://pagure.io/fedora-infrastructure/issue/9322 ================== # EPEL PLAYGROUND We have added an additional set of channels for EPEL-8 called playground. It is meant to be sort of like Fedora Rawhide so that packagers can work on versions of software which are too fast moving or will have large API changes from what they are putting in the regular channel. Packages in epel8-playground are primarily to be used in the following manner: * To test out some new version of the package that might not be stable yet. * To test out some new packaging of the package * To test a major version change of the package that they want to land at the next epel8 minor release. * To build a package that will never be stable enough for epel8, but still could be useful to some. ## Consumers / End Users Consumers should be aware that packages in EPEL8-playground are there without any Service Level Expectations. You may want to only cherry pick packages from there as needed. EPEL8-playground is not a full EPEL release. It only has those packages that developers and maintainers are "playing" around with. Because of this, you should not expect to enable only epel-playground and get everything you need. It is expected that you have regular epel enabled whenever you enable epel-playground. ## Developers / Maintainers epel8-playground builds are NOT automatically built when you build in epel8. This is a change from the original vision. #(Remove this sentence after a few years) You must use the epel8-playground branch and build from there, just like you would any other Fedora / EPEL build area. Packages in epel-playground will never be automatically put into regular epel. That is the responsibility of the package maintainer. It is recommended that if a maintainer plans to bring a package that has a large change from epel-playground to regular epel, they do it at minor RHEL releases (ie, 8.3, 8.4). Since end users will be upgrading and paying more attention than usual at those times, it’s a great chance to make larger changes. Be sure to announce those major changes well in advance on epel-devel and epel-announce. When a maintainer is done with their package in playground, they must untag all builds of it out of epel-playground. We do not want epel-playground cluttered with old test packages. Done means either the package has been moved to regular EPEL, and / or the maintainer no longer wants to play and test in epel-playground. Untagging all builds of a package is currently done via a release engineering ticket. EPEL Playground has traits similar to Fedora Rawhide. * Built packages do not need to be tagged with override to get into the epel8-playground build repository. They will be put in the next time the build repository is refreshed. This is usually within 15 to 60 minutes. * The main epel8-playground repository is built once a day, just like Fedora Rawhide. Thus built packages are usually available in epel8-playground the day after they are built. _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
