On Thu, 2007-12-20 at 10:19 -0900, Jeff Spaleta wrote:
On Dec 20, 2007 10:05 AM, Michael Schwendt mschwendt.tmp0701.nospam@arcor.de wrote:
That's easy. The spec %changelog entry already ought to explain why the update is important. It's the many hundreds small/minor/unimportant updates which fill the updates repository and drift away from the original release of the distribution. It leads to a scenario where after firstboot you are offered so many packages that you're annoyed.
The spoken question here is... are we doing releases the 'right' way for our target users?
Which target user audience?
As far as I am concerned (power user, developer): No, Fedora doesn't.
Is our release and updates policy inconsistent?
Yes. I feel Fedora is applying rel-eng strategies which do not fit into a "forward looking" distro aiming at early adoption of "leading edge technology".
IMO, it's natural for a leading edge/early technology adopter distro to see frequent updates. But also note that "leading edge" shouldn't mean "instable" or "premature". Unfortunately I also feel this is what some people (esp. some people at RH) seem to be wanting to treat Fedora as.
If lots and lots of updates cause annoyance for fresh installed users, should we be making a bigger deal about point people to re-spins as an option?
Yes. I think, there should be regular respins of the disk-images.
Just consider the current situation: The FC8 *.isos already have become obsolete and are not really worth downloading anymore.
More generally speaking, /me thinks the concept of "gold image" has reached its technical limits and won't lead much further. A bit far fetching, I think, Fedora needs bootimages supporting networked installs directly from Everything/ and some means to cut isos to for local reuse after installation.
Also assuming we can have client side tools which could be told to "update only package updates flagged as security related" on a daily basis from the network, people could grab a snapshot of the updates tree when they want to for anything non-critical.
No, it don't think this is useful. To low-bandwith users it's not the number of packages, which are causing problems, it's the mass (Which happen to originate from a handful of packages which normally are marked security update) and from unreliability of the technology underneath (such as mirrors out of sync, broken metadata, yum issues).
Ralf