John Poelstra wrote:
Hasn't the door already been opened for this? http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-19 http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-19#t13:44
The Release Meeting addressed releasing spins via Jigdo, yes.
What had been proposed -and accepted- in the Release Meeting though was releasing /custom/ spins built of the release tree, via Jigdo. In particular the Everything Spin comes to mind, composed of the full tree in releases/$releasever/Everything/$basearch. However, Jonathan's mail addresses a request to keep signed copies of updates available in updates/$releasever/$basearch (or somewhere else) for the entire release cycle, so that:
- Re-Spins and Remixes can be composed at any time during the release cycle and hosted with the Fedora Project without too large a footprint, and
- Optionally older packages can be used by respinners and remixes, when needed, for example in case of a yum or rpm update that breaks its compatibilities with anaconda, or a kernel that just doesn't do the job.
Also, I see an incomplete feature page here: http://fedoraproject.org/wiki/Features/JigdoRelease
As the owner of the feature; Jigdo hasn't got the integration bits yet to make full use of Fedora Project infrastructure, as I'm working with upstream to get some changes done, and pyJigdo (a python alternative "wrapper" around upstream Jigdo that does integrate it with the existing Fedora Project in full), hasn't been released stable yet. Then again, mind that it is an alternative. If people really start using Jigdo it hits the mirrorlist for every single slice -possibly (or inevitably) overloading the mirrorlist. With pyJigdo this problem, and another couple of problems are solved (such as multi-image downloading, error recovery, scanning more then one local directory for slices, ..., ...).
-Jeroen