Jigdo - A Professional Letter to Mike McGrath

[Jeroen van Meeuwen]

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