Ticket #3575 (closed task: wontfix)
Provide deltaisos for development releases
|Reported by:||kparal||Owned by:||rel-eng@…|
|Keywords:||Cc:||robatino, jlaska, rhe, jkeating, poelstra|
Currently Fedora 13 is in a development, that means Test Composes, Release Candidates and Final versions of Alpha/Beta/Final? milestones are regularly released. During this period there may be even several releases in one week. Each release consists of 1x 3.5GB DVD, 6x 700MB CD, 1x 200MB netinst image and 1x 1GB LiveCD. This is created for i386 and x86_64 architectures.
This is quite large amount of data. Every person interested in occasional or regular testing must download substantial part of this release. That makes certain demands on user's internet connection and also RelEng infrastructure (internet bandwidth, I/O).
Release Engineering team will create a deltaiso file for every release of current Fedora development series. This deltaiso file will contain differences between that particular release and a previous release. That means deltaisos will be created in this fashion:
- Fedora 13 Alpha TC1 -> Fedora 13 Alpha TC2
- Fedora 13 Alpha TC2 -> Fedora 13 Alpha RC1
- Fedora 13 Alpha RC1 -> Fedora 13 Alpha
- Fedora 13 Alpha -> Fedora 13 Beta TC1
- Fedora 13 Beta TC1 -> Fedora 13 Beta RC1
- Fedora 13 Beta RC1 -> Fedora 13 Beta RC2
- Fedora 13 Beta RC2 -> Fedora 13 Beta
- Fedora 13 Beta -> Fedora 13 (Final) TC1
- Fedora 13 (Final) TC1 -> Fedora 13 (Final) RC1
- Fedora 13 (Final) RC1 -> Fedora 13 (Final) RC2
- Fedora 13 (Final) RC2 -> Fedora 13 (Final)
Because deltaisos are useful typically for media that consists mainly of RPM files this process would involve mainly DVD image and would not involve LiveCD. For other media (CD, netinst) the decision is still to be made. Deltaisos for DVDs are typically around 100MB.
Deltaisos will be stored in a single directory (e.g. deltaisos/ in /pub/alt/stage), so it is easy to convert any older ISO the user currently has into a new one, even several releases forward. These deltaisos will be stored for the period of the development release - beginning with Fxx Alpha TC and ending with Fxx Final (with a small extra time after the final release to allow people to upgrade their ISOs to the final release).
The deltaiso creation process may be easily automated and is described on our wiki. No additional human interaction should be needed.
The main reason for this proposal is to enable people with slower internet connection to participate in installation testing. This often involves not only developing countries, but also highly-developed countries like the USA. I believe that although some more people would be interested in doing installation testing, it is currently too expensive for them from download time and bandwidth perspective.
Quite interestingly this also includes me as a Red Hat employee. While it is my job to perform installation testing regularly, our office does not have internet line thick enough such that I could afford downloading DVD-sized images several times a week. Performing regular nightly mirroring is not an option when new releases may be pushed even daily.
Up till now Andre Robatino (CCed) has been performing the repetitive task of downloading every development release for every architecture, creating deltaisos and publishing them as torrents (because he doesn't have any publicly available storage). Our evidence shows that these torrents are used, which means they are useful for people (and his work is invaluable for me personally). QA has started to exploit his work officially on every installation testing page.
The problem is that Andre is usually the only seeder, so the download speed is really slow and there are connection problems sometimes, so people often complain about it. Second problem is that those deltaisos are published with a noticeable delay (Andre has to detect new release, download, build, upload and announce). Overall this a huge waste of Andre's time and energy. A defined and automated process from RelEng side would simplify all of this and improve the experience for our users a lot.
Another benefit would be lowered IO/bandwidth load on Fedora infrastructure.