Hello Kevin,
Friday, March 12, 2010, 5:33:15 PM, you wrote:
> Al Dunsmuir wrote:
>>> On Fri, 12 Mar 2010 21:21:41 +0100
>>> Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
>>
>>>> The problem with all the proposals centered on the idea of N-1 as
>>>> conservative, N as less conservative, including yours above and
>>>> jreznik's, is that it forces all the people who expect a constant
>>>> type of updates to upgrade twice as often, i.e. twice a year.
>>>> Especially for the conservative folks, this will be a big annoyance.
>>>> With low bandwidths, you have to get a CD/DVD shipped each time! In
>>>> addition, I think the inconsistency will confuse our users a lot.
>>
>> Fedora has traditionally supported upgrading from not just N-1, but
>> also N-2. Folks often skip releases, especially if they are aware of
>> problems (such as the pulseaudio and X issues) with a new release.
> That's the whole point! People do this now, but having the two current
> releases be supported in a radically different way (with radically different
> update strategies) would make this no longer a viable option for many
> people.
> Kevin Kofler
One could argue that one a bit differently. Assuming the following releases:
* N (upgrade target) current
* N-1 less current than N by factor X
* N-2 less current than N-1 by factor Y
less current than N-2 by factor Z
Say Y is 3 times larger than X (1/3 of the equivalent updates).
You are going to point out that the user will see a very large change
(Z) as they upgrade from N-2 to N. This may be a large transition,
with significant learning and configuration involved. Keeping N-1 and
N-2 close to N reduces that. No argument for that point.
What some of us are arguing is that the risk and cost (to the users in
time, effort) for our user base increases as the release ages.
Slowing down the stream of updates that are for low priority bug fixes
and new feature increases Y over X. It helps to keep the release more
stable (same bugs/behaviour) for users at that release. Less updates
on average means less chance of a regression. It also means those
updates that do go out are likely better reviewed and tested.
One of the common problems with updates is where release N-1 or N-2
have a package at a newer level than the equivalent package on release
N. This can easily happen due to differences in the propagation of
updates to the various mirror, or if the release N package spends just
a bit more time in updates-testing than the others, and misses a
window to go to stable. The risk that this happening increases if one
does final builds for a given fix simultaneously in multiple releases.
Staggering the builds and doing N, then N-1, then N-2 with time to
have users validate each minimizes that risk.
Different users are willing to accept different risks, but I would
submit that a user running release N has demonstrated their
willingness to risk the update. Users in release N-1 and N-2 have
also demonstrated either their inability to update (bugs) or
unwillingness to update. What some of us are proposing is that the
updates for each release should reflect those demographics.
Al
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
