Stable Release Updates types proposal

[Al Dunsmuir]

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 at chello.at> 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