| NEWS: (updated 2008-09-30) Infrastructure status | New SSH fingerprints | New package signing key |
RudolfKastl/Proposal
From FedoraProject
Contents |
Experimental Repository Proposal
What?
A pre rawhide repository for field testing new software before it hits rawhide or testing repositorys.
Why?
To speed up development cycles and to get software ready faster for rawhide/core/extras and to enhance the quality of existing software that isnt ready for core/extras inclusion
Where?
To be discussed. At a later stage hopefully this all happens in central fedora facilities such as the fedora buildsystem as well as the fedora/redhat bugzilla
Who?
Fedora developers and the community.
Faq:
What software could go into such a repository?
- Software beeing reviewed for inclusion for early building and field testing
- Problematic software not ready yet for inclusion
- Software that is yet only packaged in 3rd party repositorys could be built in a core/extras combatible way
Why not just put the packages into -testing?
Simply because -testing isnt the appropriate place for new additions. someone that enables experimental wants to test new experimental things without beeing hit by potential bugs potentially introduced by -testing repositorys for existing stable packages on the stable os trees. For rawhide no such thing as testing exists.
What would be the benefits for Developers?
- Getting software fieldtested and built on various platforms
- Early bug reports lead to faster fixes
- Enhanced qa and less build problem support overhead if packages exist
- Less support overhead due to conflicting 3rd repositorys
- Central package QA
What would be the benefits for end users?
- No more need for conflicting repositorys
- Central place to report bugs/problems
- More software demands fulfilled
But some 3rd party repositorys require the installation of core replacements to have properly working applications! What will happen to those?
To speed up the development cycles of experimental patches to core/extras components an "experimental-backports" repository would help providing the necassery means.
How do you get the updating to packages that get included properly working?
Simply by prefixing the releasetag with "0.0."
But arent there backdraws?
Yes, there is one backdraw. Someone has to do the work.
And how would it embed in the test/qa cycle?
Packages spin their rounds in experimental until they are approved. Bugs are reported upstream (buildbugs/software bugs/integration problems).
But how do you determine when a package has been tested enough?
Thats a point that has to be discussed. Its hard to measure "enough tested".
