RCs for Everyone (was One (more) week slip of Fedora 11 Release)

[Bill Davidsen]

Jesse Keating wrote:
> On Sat, 2009-05-30 at 11:26 -0400, Bill Davidsen wrote:
>> Since that's not required, the question needs no answer. The idea is to get the 
>> changed files to the users, then assemble them into the RC candidate at the 
>> tester's end. Download the changes, including any to the "make an RC" metadata 
>> file, then run the tool of choice to generate the install media.
>>
>> The nice thing about this is that it's useful day-to-day, if I need to do an 
>> install I can build an install ISO which is up-to-date (and has some unique 
>> release number or date in the metadata), and not do the dance of installing a 
>> bunch of obsolete packages and then updating them, which beats the network and 
>> servers a lot more than people who do a lot of installs keeping an rsync 
>> current. It would also encourage a "standard" full install, dual layer DVD 
>> burners are standard these days, another reduction in load and bandwidth could 
>> be had.
>>
> 
> I'm afraid I'm not following your logic.  Torrents aren't free, either
> the torrent server is going to have to give everybody the bits, or
> somebody is going to have to download them outside of the torrent and
> seed them for people.
> 
Everyone seeds for people, the server should not be seeding more than 1-2 
clients, who then seed other, and others, leaving the server to do only bookkeeping.

> If you have a real proposal here, I suggest you write it up as a wiki
> page and bring it to the attention of mroe than just the test list.
> 
At the moment I'm locating pieces to have a proposal which is based on using 
existing parts rather than starting with a blank screen. And it feels as though 
discussion of a lower overhead means of propagating rapid changes is on topic 
here, since people trying new software tend to see a higher rate of upgrade than 
people using a more stable version.

I get the impression that jigdo is out of favor for some reason, but it does 
what I had in mind, allow the end user to create an install media as often as 
needed, and just upgrade the jigdo file and go. If the jigdo control file 
created a dated ISO image, it could be updated very regularly. And if editing 
the jigdo file were easier people could add their own list of non-default 
packages if they were creating a 8.5GB image.

It appears to be as easy as updating the jigdo file, which may be done already 
if you do internal daily (or frequent) install media creation for testing.

There, that didn't take a wiki page, all it needs is a comment on the state of 
the tools needed.

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot