Stable Release Updates types proposal

[Kevin Kofler]

Al Dunsmuir wrote:
> 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.

Huh? That was not my point at all! Please reread what I actually wrote! You 
are arguing against a strawman.

> 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,

This is pretty much a non-issue. Mirroring delays are measured in hours at 
most.

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

That doesn't happen if the push to stable is requested by the maintainer for 
all releases at once (starting from the newest, in case you're worried about 
the push happening right in the few seconds between the requests for n and 
n+1 coming in). In fact that's the whole reason why I think we should 
consider testing together for all releases and not separately for each (the 
latter being what you proposed in a different thread).

        Kevin Kofler