It is still under construction and content may change. Do not rely on the information on this page. This document will eventually contain a roadmap for implementing the Playground repository. It will outline what the playground repository is and what groups, manpower, and other resources will be needed in order to implement it.
The Playground repository gives contributors a place to host packages that are not up to the standards of the main Fedora repository but may still be useful to other users. For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repositories and packages that are never going to make it there. Users of the repository should be willing to endure a certain amount of instability when using packages from here.
All packages in Playground must play nice - no bad licenses, no proprietary software, no patented software.
Description
Policies
- Packages must follow the Legal Guidelines. In particular, the license for all packages must be approved in the Legal Guidelines.
- Packages may violate other Fedora Packaging Guidelines.
How the repository will work
Packages for the repository are built in COPR. The COPR owner can mark the repository as a whole as being part of the Playground repository. Packages successfully built for marked COPRs are copied into the Playground Repository. [marcela] Who is COPR owner? The project owner on COPR? We need additional feature in COPR for "mark as worth of Playground".
Identified needs
| Groups to Coordinate with | How necessary | Need |
| Infra | Necessary | Disk space for the yum repositories (Open question -- is this mirrored?) |
| Infra/Copr devs | Very nice to have | Copr deployment that's considered reliable enough to build packages for this repo |
| Copr devs | Necessary | Ability to mark an individual COPR for inclusion in the Playground repository |
| Copr devs | Optional but nice to have | Build from a git repository URL and revision hash |
Open Questions
We'll need to answer these questions and by their answers, flesh out the [#Description] and add additional work items to the [#Identified_needs] section.
- deltarpms?
- signing?
- it takes 4 months to implement in Copr
- how do updates work (rolling? bodhi? Will we constantly be regenerating the repodata [like the rawhide build repo?])
- rolling + constantly regenerating repodata
- one repo per Fedora release + arch
- daily push
- bodhi - no need yet (it's just Playground)
- is there a testing repo?
- testing repo - not needed, testing are COPRs
- does it need adding to mirrormanager?
- will fedup support upgrades with packages there?
- Does it need to be mashed in order to get multilib support?
- self hosting (all packages needed to build the packages are in the repo)?
- Is there any review of repos/packages in the repos?
- Does the review differ depending on who is building the package (cla+1 vs in the packager group)?
- Do we allow conflicts with packages in the main repo?
- Do we allow replacement of packages in the main repo?
- Do we allow "backdoor replacement" of packages in the main repo? ie: Let's say I have a package in the playground repo: NetworkManager2.1. And that conflicts with NetworkManager. Is that allowed? Is it allowed as long as it doesn't have any virtual provides/obsoletes that would automatically allow it to replace the package in the main repo?
- Do we allow conflicts between packages in the Playground Repo?
- Do we allow replacement of other packages in the Playground Repository? (How do we stop this in our implementation?)
- Do we allow "backdoor replacement" in the playground repo?
- How do we deal with multiple versions of same package provided by different COPRs?
Problems
1 Big repo vs multiple small ones
Ideally users would enable just one "playgrond" repo and would get all nice updates. However this has several issues:
- We'd need support in rel-eng for multiple versions of identical package (problems with composes)
- Users would get *all* playground packages not just ones they are interested in
- There is no way to specify which packages from playground to install (or they are inadequate)
Most likely better approach is repo-of-repos where:
- Each project has a COPR repo (already done since that's how they are built)
- Playground repo contains these repo files
- We can add GUI support for enabling on per-feature basis (i.e. install playground repo for "Dajngo 1.6" or "Chromium" or ...)
- Possible conflicts are between features. It's not ideal but that way there *can* be conflicts and they are not catastrophic. People who want to test django do not necessarily want to test Chromium (or other way around)