From Fedora Project Wiki
< Changes
(→Scope) |
|||
| Line 75: | Line 75: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Other developers: | * Other developers: | ||
** Copr devs | |||
*** Ability to mark an individual COPR for inclusion in the Playground repository. | |||
*** Build from a git repository URL and revision hash | |||
*** Copr deployment that's considered reliable enough to build packages for this repo | |||
** Infra | |||
*** Disk space for the yum/dnf repositories | |||
*** Continuously regenerating repodata | |||
*** Daily composes of the Playground repository | |||
*** Copr deployment that's considered reliable enough to build packages for this repo | |||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 82: | Line 91: | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | ||
* Policies and guidelines: | * Policies and guidelines: | ||
** 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. | |||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
Revision as of 15:51, 26 March 2014
Playgrounds repository
Summary
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 to use packages from here.
All packages in Playground must play nice - no bad licenses, no proprietary software, no patented software.
Owner
- Name: Your Name
- Email: <your email address so we can contact you, invite you to meetings, etc.>
- Release notes owner:
- Responsible WG: Env and Stacks WG
Current status
- Targeted release: Fedora 21
- Last updated: 2014-03-01
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
For now the whole proposal lives [here].
Benefit to Fedora
The main benefit will be easily installable software, which:
- could be for a long time in review queue, waiting for reviewers.
- is ugly or hard to package and review (e.g. bundling).
- has requirements on different version of libraries than currently is in Fedora.
Users can install more packages, developers can offer their packages more quickly.
Scope
- Proposal owners: Env and Stack WG
- Other developers:
- Copr devs
- Ability to mark an individual COPR for inclusion in the Playground repository.
- Build from a git repository URL and revision hash
- Copr deployment that's considered reliable enough to build packages for this repo
- Infra
- Disk space for the yum/dnf repositories
- Continuously regenerating repodata
- Daily composes of the Playground repository
- Copr deployment that's considered reliable enough to build packages for this repo
- Copr devs
- Release engineering: As a nice to have will be wanted deltarpms, multilib. It's not a blocker for this feature.
- Policies and guidelines:
- 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.
Upgrade/compatibility impact
Main repository won't be harmed by Playground.
How To Test
0. Build your package or set of packages in Copr
1. Ask for marking your packages as Playground
2. Wait for addition into Playground repository
3. Add Playground repo and install by PackageKit/yum
N/A (not a System Wide Change)
User Experience
N/A (not a System Wide Change)
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), No
- Blocks product? Doesn't block a product. Another repo, different than Playground, could be, but we are not providing any other at this moment.
Documentation
Will be.