Monthly Updates versus Monthly Images
dmitrij.ledkov at ubuntu.com
Wed Mar 6 21:58:41 UTC 2013
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.
> 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%. 
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
- 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. 
Any other proposals  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
[*] to be true for -proposed -> -release migrations really soon =)
 phased updates spec is here https://wiki.ubuntu.com/PhasedUpdates
 assume that phasing at 101 for security updates still counts as phasing =)
 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?! =))))))
More information about the ubuntu-devel