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@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
