William Hooper wrote:
Robin Laing wrote:
Why not automate the packages to be the latest? Isn't this what
computers are supposed to be good at? How hard would it be to make a
bi-weekly package. Release the packages as FCx.yymmdd The ISO's would
just be created from the current packages. The date code provides users
to know the date of the image.
And how many mirrors want to transfer an extra ~12 GB bi-weekly? That's
just for the ISOs. Double that for the exploded trees.
And how many people want to test these ISO sets bi-weekly to make sure no
bugs have creeped in?
And how long does the none-technical side of creating new ISOs take? In
the past ISOs have been ready a week early, but were waiting on
non-technical issues.
There is no reason to upload or change everything. Just the iso's as
the rest of the trees are covered in the updates.
Okay, the ISO's could be created once a month. All the files are
already on the mirrors so they could create them locally from the
updates already released. At least some of the mirrors could.
Don't confuse the issue of creating a "new" package. All I am saying
is that the present package is just repackaged with the latest
releases of the updates. All the packages have been tested before
going into updates.
To give an example. Lets say that last month, the latest kernel was
2.6.12-1.1456 but this week it is 2.6.13-1.1532. The set uses the
2.6.13-1.1532 kernel (and all associated files). No added packages or
extended features. If you cannot get to the set by doing "yum update
all" then it doesn't go into the set.
It doesn't take me long to create a DVD ISO using k3b.
This is just an idea off of the top of my head. The thing I hear from
others is about downloading the ISO, burning a DVD and then needing to
spend a few hours waiting for the updates to be downloaded and
installed. The above approach would at least get a fairly recent set
of files with current updates on their computers.
--
Robin Laing
