Re: Monthly Updates versus Monthly Images
On 7 March 2013 09:37, Robie Basak wrote: > On Wed, Mar 06, 2013 at 09:58:41PM +, Dmitrijs Ledkovs wrote: >> 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%. > > From the spec: > A computer is in the testing set if > Phased-Update-Percentage ✕ 2^128 >≥ > md5(machine id + package name + package version). > > With precise-updates (for example), ordering of phasing between packages > doesn't matter, since the dependency tree generally remains the same. > It does and it doesn't. So for example foo:src can build foo:amd64 and foo-data:all with a strong version matching dependency. I think it's nice to consider this as a general case, stress test phasing in the development release before starting to use it for the SRUs. In general SRUs, will have less packages in phasing simultaneously with much "lighter" dependency resolution. > With rolling updates, won't phasing ordering start to matter? What > happens if the results of my md5 cause an update to package A to be > phased in before NEW package B, and the updated A now depends on B? Yes, we should ideally, consider all dependency variants, with all combinations of which packages "md5/phasing" hits/chooses to install _now_ and record them in the test-suite. > Presumably dist-upgrade can hold that specific case automatically, but: > apt-get / aptitude have no idea about phasing at the moment. So any dist-upgrade from command-line / synaptic will be as if you agree to install all packages even if at 0% phasing. Only update-manager knows about phasing. We do not want to hold any special cases. Instead we will agree that if we choose to install a phased update, it's dependencies must be satisfied and upgraded as necessary required. That means that the update will succeed, but it will also mean that we are overphasing[1] some packages. In the simple case of foo & foo-data, if one "hits" either of updates both are installed. In the more complex case (a lot of reverse dependencies) e.g. like a core library libgtk, the overphasing will be much significant, thus core packages should be (a) tested more before uploads (b) phase much slower, as reverse-dependencies will overphase them. > 1) Are there more complex cases that will break things? > In theory, since apt-get is in the end installing packages and should resolve all dependencies correctly, it should all just work ;-) But we do not now yet what happens in the corner cases. We have test-suites in the update-manager and cjwatson, ev and I discussed to improve it with more "lets see, what if this happens". > 2) Is holding going to cause any other problems? User confusion? More > invalid bugs as people wonder why they can't install things or "fully > update"? This point is moot, since `apt-get dist-upgrade` should always work (due to britney installability transitions) and we ignore phased updates constraints when resolving dependency chains of the phased-update. Ideally I'd like to see phased-updates to be installed silently / automatically. Just like apps are updated on the phones. [1] defining "overphasing" is tricky, as we have no control over how often users connect to the internet and/or set their dials to automatically refresh package lists and actually apply phased updates. It's purely theoretical relative comparison between packages. Regards, Dmitrijs. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On Wed, Mar 06, 2013 at 09:58:41PM +, Dmitrijs Ledkovs wrote: > 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%. From the spec: A computer is in the testing set if Phased-Update-Percentage ✕ 2^128 ≥ md5(machine id + package name + package version). With precise-updates (for example), ordering of phasing between packages doesn't matter, since the dependency tree generally remains the same. With rolling updates, won't phasing ordering start to matter? What happens if the results of my md5 cause an update to package A to be phased in before NEW package B, and the updated A now depends on B? Presumably dist-upgrade can hold that specific case automatically, but: 1) Are there more complex cases that will break things? 2) Is holding going to cause any other problems? User confusion? More invalid bugs as people wonder why they can't install things or "fully update"? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On 6 March 2013 13:37, Harald Sitter 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On Wed, Mar 06, 2013, Allison Randal wrote: > I was nodding along with this, and beginning to picture a 3-pocket model Indeed, sounds completely in line; however not sure about: * number of pockets * actual transition logic between them For instance today raring-proposed to raring migration doesn't protect end-users enough, and I don't see how any kind of automated migration could be enough, yet it would seem to be a big burden to manually copy things that are ready. Any fixed propagation delay like 10 days would seem to be either too long or too short depending on what we're trying to land. We also want peer reviews somewhere. Finally, I'm not sure we can fit all the *buntu builds with the same workflow; it worries me that we'd enforce the same transition logic to e.g. unseeded universe packages and boot infrastructure. -- Loïc Minier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On 03/06/2013 04:21 AM, Loïc Minier wrote: > > If I take Chrome as an example, I can see how you can be interested in > testing latest crack to integrate with it, report issues with it, get it > first before you're interested etc. but you know you might get bugs; so > you'd be on the beta or dev channels, just like one can get Firefox > beta. But most users are on the stable channel or use the non-beta > Firefox and they get updates all the time, but updates that have been > staged in various ways and hit them from time to time, often without > them even noticing. > > > There might be a fundamental split here between server deployments or > old-world IT approaches where you want tight control over what comes in, > use the same bits for a long-period. Clearly that's not what we want > for client where we want our stuff to reach as many people as possible > as soon as possible, but not too soon as it needs to be good enough. > The current -proposed step isn't sufficient to stage changes; the > proposed monthly releases might be more suitable, but I don't really > like them because they are either suck too much effort to get them good > enough or they would not be good enough. I was nodding along with this, and beginning to picture a 3-pocket model where: * -proposed is the cowboy-country where Debian syncs are automatic, FTBFS and other issues are held for developers to fix before packages go on to, * -testing is a solid candidate for end users, and where integration testing and translation work are done. On a regular cadence (monthly? weekly?) packages move as a set into, * The end-user visible archive. When a user is running the "rolling release" they get updates from this archive, not from -proposed or -testing. This is analogous to a DevOps model of "local VM" (where anything goes), a staging server, and a production server. Or in source control a topic branch, an integration branch, and a release branch. > My preference would be for some kind of Ubuntu + Unity base rootfs that > people can't touch; their apps are installed in some separate hierarchy > and they can update their Ubuntu + Unity base rootfs efficiently all the > time to get security fixes and latest features. We would have an easy > way to push an update for a security fix, and an easy way to stage what > goes in it. We do need some branch of (a subset of) the archive to > build that though. This sounds like an "abort" button when things go really, badly wrong. But not a solution to providing a stable user experience. Conflicts between installed apps and the base are real regressions. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
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. 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. HS -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On Wed, Mar 06, 2013, Robert Collins wrote: > I think this is backwards: we're trying to cross the chasm; users > don't want to have to care about updates *ever* - the industry is > moving to a model where knowing that something has updated, or not, is > quaint. First websites started to evolve rapidly, with occasional > 'whats new' dialogues, a long time back now virus scanners and other > critical time-sensitive components on other operating systems started > just keeping themselves up to date all the time, and less critical > components prompt. The toplevel idea that users shouldn't care about updates is great. Some advanced users do care about updates, but most end-users shouldn't have to worry about applying security or stable updates or getting new versions at any time. This is the experience you get with new Chrome/ChromeOS, new Firefox, new websites, new Android or iOS apps. You might get a summary of the changes if you care. People reading this thread might be reading the changelog of security updates, but non-IT folks just press the big "apply all updates" button or just get the updates applied in the background. I don't think the problem is with the size of the updates though; at the moment we bundle the OS and the apps in one large archive where everything in it has to transition in lock-step and where end-users can combine things in a crazy number of ways, allowing them to e.g. update only this or that part of their system. It's urgent that we draw some lines between things that are core in this or that Ubuntu flavor (you can't touch these, these get updated regularly wholesale and unintrusively for you) and things you add on top (mainly apps, that need to keep working because they are built on a decently stable API). Another major difference is in time-based releases vs. rolling vs. roughly monthly releases. Pushing end-users to LTSes is too limiting for us; it would take too long for people to consume our work. Pushing them daily stuff is too aggressive. We're still doing sourceful uploads without any kind of manual testing, we're stll getting regressions every day without any kind of human testing before it reaches everyone on the rolling release. These get fixed quickly, but this should not reach regular non-developers. > Most users *do not have* the knowledge about our development practices > and the reliability we achieve to reason about 'should I update daily, > weekly, monthly or 2 years'. It is a nonsensical question. They can > reason about how much risk they are willing to take: 'No risk at all > of new things breaking but I may get cracked and nothing gets better' > / 'Low risk of things breaking but I get security updates to avoid > crackers - but nothing gets better' / 'Things might break but I get > security updates and the software gets better.' I don't even know whether we want that many choices, but clearly that's what we should be thinking about. If I take Chrome as an example, I can see how you can be interested in testing latest crack to integrate with it, report issues with it, get it first before you're interested etc. but you know you might get bugs; so you'd be on the beta or dev channels, just like one can get Firefox beta. But most users are on the stable channel or use the non-beta Firefox and they get updates all the time, but updates that have been staged in various ways and hit them from time to time, often without them even noticing. There might be a fundamental split here between server deployments or old-world IT approaches where you want tight control over what comes in, use the same bits for a long-period. Clearly that's not what we want for client where we want our stuff to reach as many people as possible as soon as possible, but not too soon as it needs to be good enough. The current -proposed step isn't sufficient to stage changes; the proposed monthly releases might be more suitable, but I don't really like them because they are either suck too much effort to get them good enough or they would not be good enough. My preference would be for some kind of Ubuntu + Unity base rootfs that people can't touch; their apps are installed in some separate hierarchy and they can update their Ubuntu + Unity base rootfs efficiently all the time to get security fixes and latest features. We would have an easy way to push an update for a security fix, and an easy way to stage what goes in it. We do need some branch of (a subset of) the archive to build that though. -- Loïc Minier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On Wednesday, March 06, 2013 04:12:16 PM Robert Collins wrote: > On 6 March 2013 12:20, Scott Kitterman wrote: > >> critical updates. I think leveraging phased-updates to that end is a > >> fairly simple, lightweight, and elegant solution that completely avoids > >> the > >> harm and complexity of any of the proposed monthly updates schemes. > > > > I think for phased updates to be meaningful in this context it would have > > to be a bit different. As (IIRC) Highvoltage mentioned, he wants to be > > at the back of the iceberg: > > > > http://hellenicpolytheist.files.wordpress.com/2012/07/killer_whale_eating_ > > penguins- jump-in-air.jpg > > > > 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. > > I think this is backwards: we're trying to cross the chasm; users > don't want to have to care about updates *ever* - the industry is > moving to a model where knowing that something has updated, or not, is > quaint. First websites started to evolve rapidly, with occasional > 'whats new' dialogues, a long time back now virus scanners and other > critical time-sensitive components on other operating systems started > just keeping themselves up to date all the time, and less critical > components prompt. > > Most users *do not have* the knowledge about our development practices > and the reliability we achieve to reason about 'should I update daily, > weekly, monthly or 2 years'. It is a nonsensical question. They can > reason about how much risk they are willing to take: 'No risk at all > of new things breaking but I may get cracked and nothing gets better' > / 'Low risk of things breaking but I get security updates to avoid > crackers - but nothing gets better' / 'Things might break but I get > security updates and the software gets better.' > > Exact frequency is *only* meaningful because we have bugs in our > delivery infrastructure: we routinely ship 10 or 100 times as much > data as is needed (no binary deltas); we ship 10 to 100 times as much > metadata as is needed by most users (complete archive index for > everyone all the time, and no archive deltas); installation of package > updates reads again, 10 to 100 times as much data as is being altered > (change 10 packages on a system with 1000 installed, but we read the > full dpkg status file, the complete list of all files installed by any > package...); dpkg is slow (because it works very hard to be atomic). > > Now clearly we can't wave a hand and just fix all those issues (and > there probably will even be debate about whether they are all in fact > issues :p) - but when we design what we want to achieve, lets design > around our users, what we can reasonably expect them to know and care > about, rather than around the plumbing we happen to have today, which > they assuredly are not interested in. If that's the kind of users we're targeting with the rolling concept, then it's way premature to consider switching to it. That doesn't mean we can't define the technical needs that would make us ready and start working towards it now, but execution should not precede readiness. If the target is a more advanced "enthusiast" user, then I think they do know about updates and will have some care about them. I'm not proposing that we give rolling users a knob to turn to decide how far back on the iceberg they want to be, just that there be an offset for "enthusiast users" who are not directly involved in development. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On Mar 06, 2013, at 04:12 PM, Robert Collins wrote: >I think this is backwards: we're trying to cross the chasm; users >don't want to have to care about updates *ever* My observation of, let's call them my local users, backs this up. It drives me crazy to see the various software delivery tools (e.g. iTunes) have *dozens* of updates available with nothing updated in months. Worse is the resistance I get when I suggest that it's time to update the OS or apps, not because it takes so long to download and apply them, but because of the risk/reward tradeoff. There's little perceived reward in a system that might be a bit more secure, but there's a lot of risk that some favored feature, or somewhat annoying bug that has been carefully worked around is replaced by an even more disruptive bug that breaks their flow and has an even more painful or unknown workaround. I think we've just got at least two types of audiences. One is happy that they have something that works and works for them, and doesn't much care about the latest and greatest. The other wants bleeding edge coolness and can handle the pain that goes along with that. Or maybe: "Change is the only constant"[1] vs. "We Fear Change"[2]. ;) -Barry [1] http://en.wikipedia.org/wiki/Impermanence [2] http://www.youtube.com/watch?v=oK9JX_Ef0Ws -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On 6 March 2013 12:20, Scott Kitterman wrote: >> critical updates. I think leveraging phased-updates to that end is a >> fairly simple, lightweight, and elegant solution that completely avoids the >> harm and complexity of any of the proposed monthly updates schemes. > > I think for phased updates to be meaningful in this context it would have to > be a bit different. As (IIRC) Highvoltage mentioned, he wants to be at the > back of the iceberg: > > http://hellenicpolytheist.files.wordpress.com/2012/07/killer_whale_eating_penguins- > jump-in-air.jpg > > 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. I think this is backwards: we're trying to cross the chasm; users don't want to have to care about updates *ever* - the industry is moving to a model where knowing that something has updated, or not, is quaint. First websites started to evolve rapidly, with occasional 'whats new' dialogues, a long time back now virus scanners and other critical time-sensitive components on other operating systems started just keeping themselves up to date all the time, and less critical components prompt. Most users *do not have* the knowledge about our development practices and the reliability we achieve to reason about 'should I update daily, weekly, monthly or 2 years'. It is a nonsensical question. They can reason about how much risk they are willing to take: 'No risk at all of new things breaking but I may get cracked and nothing gets better' / 'Low risk of things breaking but I get security updates to avoid crackers - but nothing gets better' / 'Things might break but I get security updates and the software gets better.' Exact frequency is *only* meaningful because we have bugs in our delivery infrastructure: we routinely ship 10 or 100 times as much data as is needed (no binary deltas); we ship 10 to 100 times as much metadata as is needed by most users (complete archive index for everyone all the time, and no archive deltas); installation of package updates reads again, 10 to 100 times as much data as is being altered (change 10 packages on a system with 1000 installed, but we read the full dpkg status file, the complete list of all files installed by any package...); dpkg is slow (because it works very hard to be atomic). Now clearly we can't wave a hand and just fix all those issues (and there probably will even be debate about whether they are all in fact issues :p) - but when we design what we want to achieve, lets design around our users, what we can reasonably expect them to know and care about, rather than around the plumbing we happen to have today, which they assuredly are not interested in. -Rob -- Robert Collins Distinguished Technologist HP Cloud Services -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On Tuesday, March 05, 2013 06:34:29 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. > > So, I'm intentionally breaking the thread here to shift gears slightly. I > have no intention of discussing the merits of rolling versus not, of going > on about whether now is the right time to switch, or if we need a year of > discussion before we can consider it, or any such thing. This is purely > on the topic of so-called "monthly updates" versus monthly images, and my > position that the latter could prove quite useful, while the former could > be actively harmful. If one were going to do rolling, I mostly agree with this. > We seem to be approaching this by conflating the two concepts of releases > and images as if they're both the same thing and I think we can all take a > step back and agree that, in fact, they're not. If we choose to have a > monthly milestone planning cadence for work items and release a monthly > image to wrap marketing and messaging around, there's definitely value in > that. Being able to announce to the world that we had these seven major > new features land in Xubuntu this month, these two awesome new things in > Kubuntu, these three in Lubuntu, etc, is quite nice, and probably much less > chaotic than having everyone plan to different cadences and sporadically > tell the world about things as they happen. Keeping us all on a similar > track has always proven quite helpful for interaction between teams and > flavours, and I see significant value in that continuing. > > The above stated, I see no reason why this planning cadence and image cycle > needs to, in any way, look like a "release", and I think it's actively > harmful, both to our development velocity (hey look, a buzzword, you won't > hold it against me, right?) and to our users. > > For starters, let's look at all the things I think this monthly image can't > be, if we want to maintain a lightweight process that doesn't slow us all > down and make small children weep: > > 1) We can't be doing mini freeze-and-release cycles before each image is > released. I've seen it come up several times in the thread, and this > suggestion will just slow us to a crawl. It's actively undoing any > benefit we'd get from moving to a rolling release cycle. We've done two day migration freezes for the relevant bits of the archive to support Alpha 1 and Alpha 2 in this cycle. I think short migration freezes like this (in contrast to the traditional upload freeze of 5 - 7 days) has had almost no impact on development velocity. I've found it helpful in making sure we're getting a good set of images for a milestone. I think a one or two day migration freeze would be a useful thing that wouldn't harm the goals associated with rolling in any meaningful way. > 2) We can't be providing out-of-band critical bugfix support for these > images. How they ship is how they are, and we need to trust that the > preliminary smoketesting on them before they're released is enough to > ensure an install/reboot cycle and that we won't be destroying people's > hardware, but that's about as far as we can go. > > In short, we can't be wasting engineering time on the images themselves, > or they become "releases", and everything that comes with that. The more > time we spend on the images, the less time we spend on the rolling release > itself, and the lower the quality of the LTS that comes out of the other > end of this meat grinder. > > So, looking at various solutions proposed for this dilemma, we see people > suggesting clever use of -updates and -security to attempt to simulate a > monthly release, we see people suggesting phased updates dialed down to > zero, and many other curious options. Each of these makes the assumption > that monthly updates are a good thing. Each of these ignores the following > facts, as far as I can tell: > > 1) If a nasty bug is discovered in the rolling release a day after we put > out a monthly, we either need to revisit our "no SRUs to the monthlies" > policy on a case-by-case basis, or we ask users to live with that bug > for ~29 days until the tools say "hey, cool, you can upgrade now". In > the current default setup, that bug would have been fixed in seven days > or less, as that's the default update-manager nag frequency. > > 2) Security support either needs a stable base to build on (the "freeze > the release pocket for a month" model), or it can't be provided out-of- > band. Having the security pocket depend on things that we might need > to remove from the release pocket is problematic. > > These two points feel like they're at odds to me, as freezing the world to > allow an out-of-band security model means making users live with every non- > security bug for a mont
Re: Monthly Updates versus Monthly Images
On Tue, Mar 05, 2013 at 01:19:17PM -0500, Marc Deslauriers wrote: > 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... :) > > > > 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? Phased Update Percentage, I believe. -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
On 03/05/2013 12:19 PM, Marc Deslauriers wrote: > On 13-03-05 08:34 AM, Adam Conrad wrote: > >> 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. > Isn't dropped patches always a problem, even now? I was thinking we would push 'normal' security updates to the dev release (ie, through -proposed and not in our PPA). These are the ones that we wouldn't have pushed through -security in the previous proposal. For high priority updates, we only build in our PPA unless it also exists in -proposed, in which case, we build in both our PPA and -proposed (and since we are preparing the updates, we control the versions so that shouldn't be an issue). This isn't much different than the previous proposal. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Monthly Updates versus Monthly Images
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... :) > 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. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
