Monthly Updates versus Monthly Images

[Marc Deslauriers]

On 13-03-05 08:34 AM, Adam Conrad wrote:
> TL;DR summary: Monthly updates are harmful, monthly images are cool, let's
> do the latter without turning them into the former and all frolick happily
> in fields of time, money, and cheesecake.

mmm...cheesecake... :)

<snip>
>  2) No out-of-band support at all, SRU or security.  The only slight change
>     from how we do things now would be that security updates destined for
>     the development release would be built in the security PPA (which does
>     not build against -proposed), so they don't pick up new dependencies
>     and can then be copied to the archive and not accidentally get caught
>     up in library transition snags that hinder their migration to the
>     release pocket.

I assume we would do this so the urgent security updates don't get stuck
in -proposed for a longer than desired timeframe? The problem with doing
this is it's going to be really hard for us to not collide with version
numbers, and making sure that subsequent uploads still contain the
security fix, etc. While it may be worthwhile for a world-burning issue,
I don't see this as being reasonable for the majority of security
updates for which we'll simply upload them as usual.

>  3) We twiddle the phased-updates spec a teensy bit so that P-U-P values
>     over 100 are treated by update-manager as security/critical updates,
>     and offered immediately, rather than after the configured update delay,
>     much as packages in the -security pockets are now offered.  With this
>     model, we can make the scripts that copy from the security PPA to the
>     archive set the phased update probability to 101 for security uploads,
>     and have them treated as "special" by update manager, without having to
>     actually use the -security pocket and deal with the annoyance of a
>     pocket that doesn't have a stable base to depend on.

Pardon my ignorance, but what does a "P-U-P value over 100" mean?

Marc.