Monthly Updates versus Monthly Images

[Dmitrijs Ledkovs]

On 6 March 2013 13:37, Harald Sitter <apachelogger at ubuntu.com> wrote:
> On Tuesday, March 05, 2013 06:20:14 PM Scott Kitterman wrote:
>> What's needed is not only show me updates every X days, but only show me
>> non- critical updates that are at least X days old.  I don't think we have
>> a way to express that.
>

we do with phased updates, see below.

> While I agree with the genearl notion, solving that on the client side in  a
> configurable manner would cause a whole bunch of problems and policy decisions.
>
> X=7;
> Let's assume a new KDE SC version is uploaded; an issue with kde-workspace is
> found and workspace gets a new uploaded six days after the batch upload of the
> new version.
> Seven days after the initial upload everything *but* kde-workspace would be
> ready for update.
>
> So what is the update manager expected to do? Disregard the dependency on a
> newer workspace than what is allowed to be installed and then error to the
> user "couldn't upgrade foo because deps are not met" or hold back the entire
> dependency chain?
> If rolling updates are meant to be not any more intrusive than an update on a
> LTS release, and at the same time adhere to must-be-atleast-x-days-old it
> would have to be latter and then in theory with the large pile of inter-
> dependent pieces that comprise the KDE software collection you could in theory
> block an update indefinitely by uploading a change every 6 days...
>
> It sounds wrong.
>

My view of the rolling world is this:

Everything gets uploaded into -proposed, FTBFS / installability /
components mismatches are sorted out [*] / autopkgtests [*] are run
and then the packages are finally migrated by britney into rolling as
it is currently done.

At this point all of these packages are phased at 0%. [1]
Over the period of time (e.g. 4 weeks) we gradually phase those
packages to 100%.

On the clientside one has a control:
- Install at 0% phasing, means I am the Core OS developer, Further QA,
and I want all updates as soon as possible.
- Install at 1% - 99% phasing, means I'm an enthusiast and I'd like to
receive updates before others do, but I'm not willing to be the first
one.
- Install at 100% phasing, I am a user who likes new and shiny things,
but it must not be broken.

On the server side, we have the following controls:
- Monitor bugs on lp.net, crashes submissions on errors.u.c,  reports
from manual QA and adjust phasing accordingly. E.g. reset to 0 (pull
the update), keep at the same level (while investigating an alert
condition), speed up / slow down.
- To push out a fixup upload one can upload a new version, are phased
at higher % than previous phasing (e.g. if -1 was broken and got to
20% phasing, upload -2 and start phasing it at 20%, this way broken
machines are fixed and no new machines get broken either)
-To push out a security fix we can overphase it at 101% (resonating
infinity's proposal that I shall reread again ;-) )

What about images?
Build from 0% phasing to start automatic smoke testing & fixup.
Build from 100% phasing stable enough for users to install rolling release.

All uploads into rolling must be phased. No exceptions. [2]

Any other proposals [3] so far do not seem to address the diverse
needs of our target user-base. Where developers need to push out typo
fix-ups, where users need to stay secure and updated, and where one
should be in control to trust our updates blindly (100% phasing) or be
productive at developing Ubuntu core OS (0% phasing).

I hope this sounds right, and gives flexibility to act upon
regressions in a meaningful way depending on how many users it has
reached.

[*] to be true for -proposed -> -release migrations really soon =)
[1] phased updates spec is here https://wiki.ubuntu.com/PhasedUpdates
[2] assume that phasing at 101 for security updates still counts as phasing =)
[3] i should be re-reviewing infinity's proposal again, it was tl;dr
on my phone when it came through

ps. what about phasing over 6 month period?! =))))))