On 6 March 2013 13:37, Harald Sitter <[email protected]> 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?! =)))))) -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
