Re: reflecting on first UDS session on rolling releases
On Wed, Mar 06, 2013 at 12:13:30PM -0800, Alex Chiang wrote: Let's spend our time improving plumbing like making app backports to the stable platform easy or enabling system updates on an embedded device in a sane manner or maintaining library APIs across stable releases. This still needs a constant flow of newer kernels and drivers. Which then might require newer userspace components, too. Kind regards Philipp Kern signature.asc Description: 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: reflecting on first UDS session on rolling releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bryce Harrington wrote on 06/03/13 15:45: ... He means not just the core OS but also the application ecosystem. In Windows the OS release is just the core OS, and then users manually install newer versions of whatever applications they want. As they do in Ubuntu, unless the application is in the core OS repositories. (I would argue that any software project that has their act together will have .debs for the LTS downloadable from their web site or a PPA, or even via -backports, so in practice this isn't that different. However, I believe that was the distinction he was drawing.) ... Any software project that has their act together is in MyApps. ;-) - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlE4dhcACgkQ6PUxNfU6ecoZnwCfaK4xj5d8n7sZ7u+KT9Q9/9yi 9GwAn0ueCf6QxkzDj0nY7alflh4DFY+H =VcaU -END PGP 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 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 7 March 2013 09:37, Robie Basak robie.ba...@canonical.com 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: reflecting on first UDS session on rolling releases
On Wed, Mar 06, 2013 at 07:34:55AM -0800, Allison Randal wrote: Also remember that, as the idea currently stands, the tiny set of enthusiasts are the only people who will get updated versions of applications. The majority of users will have a stale experience, and no reasonable alternative. To expand on this stale experience, I think there's a whole separate important class of users. These are users who otherwise would use the LTS, but need some particular feature or version of some program that is newer than the LTS. These users aren't necessarily self-selecting; anyone at any point may find himself in this class. I certainly have. Before I worked for Canonical I generally used six-monthly releases, but only updated when I needed or wanted something specific, upgrading through multiple releases at a time. Another example: I found that some particular wireless card didn't work except in the latest 6-monthly release. So I put my mother onto that until the next LTS was released. Here, I wanted to use the LTS but was unable, so I put her on a supported release that didn't change under her until an LTS was available. I think a rolling release would mostly serve this class of user, except perhaps in environments where multiple people want to be on the same release (eg. they are developing against a framework for which they need a newer version than the LTS). Backports and PPAs could also help solve this for some specific cases, but in general I think we need far more PPAs and backports for this to work. The problem is that the group of users who need this often aren't in a position to do the backport themselves, so it doesn't happen. Robie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On Thursday, March 07, 2013 11:52:40 AM Robie Basak wrote: On Wed, Mar 06, 2013 at 07:34:55AM -0800, Allison Randal wrote: Also remember that, as the idea currently stands, the tiny set of enthusiasts are the only people who will get updated versions of applications. The majority of users will have a stale experience, and no reasonable alternative. To expand on this stale experience, I think there's a whole separate important class of users. These are users who otherwise would use the LTS, but need some particular feature or version of some program that is newer than the LTS. These users aren't necessarily self-selecting; anyone at any point may find himself in this class. I certainly have. Before I worked for Canonical I generally used six-monthly releases, but only updated when I needed or wanted something specific, upgrading through multiple releases at a time. Another example: I found that some particular wireless card didn't work except in the latest 6-monthly release. So I put my mother onto that until the next LTS was released. Here, I wanted to use the LTS but was unable, so I put her on a supported release that didn't change under her until an LTS was available. I think a rolling release would mostly serve this class of user, except perhaps in environments where multiple people want to be on the same release (eg. they are developing against a framework for which they need a newer version than the LTS). Backports and PPAs could also help solve this for some specific cases, but in general I think we need far more PPAs and backports for this to work. The problem is that the group of users who need this often aren't in a position to do the backport themselves, so it doesn't happen. This is exactly the case that backports are for. I don't think users who want a generally stable experience, but need a thing or two newer are at all candidates for running the development release. 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: reflecting on first UDS session on rolling releases
Hi Scott (2013.03.07_16:27:02_+0200) These are users who otherwise would use the LTS, but need some particular feature or version of some program that is newer than the LTS. This is exactly the case that backports are for. I don't think users who want a generally stable experience, but need a thing or two newer are at all candidates for running the development release. Except for more complex HWE situations. (e.g. something that needs an entirely new network-manager modem-manager stack) Getting an official backport is still quite hard, though. * You have to know exactly what it is that you need backported (sometimes it's non-trivial to determine) * Then build the backport, which could be easy (no-change backport of one package) or really hard * Then file the backport bug, to request it for other people. At this point, your own needs are satisfied, so you are doing this for altruism and reproducibility. * Finally, someone has to review and sponsor the backport. That can take ages. We've gone a long way to making backports easier, but I don't think there's much low-hanging fruit left. We can provide more help, and spread the word that backports can be easy. That's about it? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On Thursday, March 07, 2013 04:43:18 PM Stefano Rivera wrote: Hi Scott (2013.03.07_16:27:02_+0200) These are users who otherwise would use the LTS, but need some particular feature or version of some program that is newer than the LTS. This is exactly the case that backports are for. I don't think users who want a generally stable experience, but need a thing or two newer are at all candidates for running the development release. Except for more complex HWE situations. (e.g. something that needs an entirely new network-manager modem-manager stack) Getting an official backport is still quite hard, though. * You have to know exactly what it is that you need backported (sometimes it's non-trivial to determine) * Then build the backport, which could be easy (no-change backport of one package) or really hard * Then file the backport bug, to request it for other people. At this point, your own needs are satisfied, so you are doing this for altruism and reproducibility. * Finally, someone has to review and sponsor the backport. That can take ages. We've gone a long way to making backports easier, but I don't think there's much low-hanging fruit left. We can provide more help, and spread the word that backports can be easy. That's about it? Mostly what we need is (like many things) more manpower. Backports are certainly not ideal for the reasons you give, but if someone is not up to dealing with the relatively modest technical requirements for getting a backport approved then I think they are very much not the kind of people that should be running the development release. 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: reflecting on first UDS session on rolling releases
On 03/07/2013 06:50 AM, Scott Kitterman wrote: We've gone a long way to making backports easier, but I don't think there's much low-hanging fruit left. We can provide more help, and spread the word that backports can be easy. That's about it? Mostly what we need is (like many things) more manpower. Backports are certainly not ideal for the reasons you give, but if someone is not up to dealing with the relatively modest technical requirements for getting a backport approved then I think they are very much not the kind of people that should be running the development release. One possible alternate future out of many would be to take a fraction of the Canonical-funded manpower that currently goes into the development releases, and put it instead into Backports. Particularly, identifying a set of packages that ordinary users are most likely to need backported to the LTS and proactively keeping them up-to-date with the latest versions of the packages. That won't cover every user's need, but it provides a stair-step between don't change anything and give me the firehose of updates, more like I really only care about the latest version of Foo. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
Proposals like moving to a rolling release are an attempt to evolve our existing processes to new realities and requirements, but I think we need to go one step farther and question why we are so tied to our distro model, where apps and platform are tightly bound. The convenience of one-stop shopping has now become a bottleneck for app deployment. Most other platforms appear to separate out delivering the platform (usually as a unified whole) from the applications (usually individually). It's an easier model to understand and better reflects the skills and expertise of most programmers. I agree the distro model was good and necessary before Linux (and Ubuntu) were popular platforms. In those days, we needed distro developers to bring apps to the platform to entice users. My claim is that we've since solved the chicken and egg problem. We *have* an enticing platform that attracts app developers from weekend hobbyists to giants like Valve. 'Solved' might be a little strong here, but I think I agree that there's enough critical mass that Ubuntu now makes it into the short list of platforms developers might support. Let's spend our time improving plumbing like making app backports to the stable platform easy or enabling system updates on an embedded device in a sane manner or maintaining library APIs across stable releases. Let's figure out how to decouple and disentangle our apps from our platform. Let's stop trying to have (and do) it all. Yup. I would say that most professional application developers would love Ubuntu to be a stable predictable platform that finds the right tradeoff between newness and risk of breaking. This includes the developer platform (the computer I write code with) and the delivery platform (the computer my customer runs my app on). As a developer, I can live with some breakage if its infrequent and I get the new stuff. As I understand it, the new automated testing regime gets us there ... eventually. Putting my app developer hat on, I want to focus on writing my application as much as possible and delegating the grotty plumbing to Ubuntu. This includes installing onto a stable platform. I'd like Ubuntu to tell me how to create an installation procedure (in English please). I don't want the Microsoft model, where people specialize just in writing installers and can pay thousands of dollars USD for the best tools to do it (https://shop.flexerasoftware.com/en/productselect.aspx). I'm not sure I want to be a captive of an app store ala Apple or Google, especially if it slows me down, or is too expensive, or causes my wonderful application to disappear in the crowd. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Potential Idea (Since it seems like Ubuntu is being completely restructured)
So, first off, I'm not an Ubuntu developer. And my Linux/Ubuntu experience is basically playing with in Virtualbox and installing as a dual-boot on a few systems. So, if I get some of the technical details wrong, don't jump all over me. This is just from the perspective a very knowledgeable computer user, yet still novice Linux user. The problem I've always had with Ubuntu is that with the way it worked, you had to upgrade everything when you went a new release (to get updated software), or you had to stay back on older software if there was something you needed (say, older video driver--especially closed source one for full features). How often does a new Gnome, KDE, Firefox, gimp, etc need a new kernel or X.org (more irrelevant now with Mir) and vice versa. The old method of LTS and periodic releases didn't really help this. LTSes were starting to once things like Firefox started to get backported. The new rolling release type idea doesn't help this -- in fact, it might make it worse since you'll always be at the leading edge. So, my proposal would be a hybrid approach. Which makes it follow more of the Windows/OSX style of really releasing an OS with apps being separate instead of the monolithic complete system that ships now. 1) break Ubuntu into cores - base OS: kernel, boot, init, most drivers (maybe graphics drivers) - graphics: graphics drivers, Mir/x.org -- these might have to be separate channels, or graphics drivers might be in the base OS - desktop environments - other applications -- Firefox, GIMP, Libreoffice, etc. 2) each core has choice between stable, current, devel/unstable - LTS would be equivalent to stable - rolling release would be current - devel would be where everything new gets uploaded 3) allow individual packages to bump up channels from the core it's part of 4) PPAs could still be used for very cutting edge things 5) for at least the base os/graphics, DEs, you could still have periodic cut points that people could be pin to (whether that's the old 6 mo or the LTS 2 years). These pinned points would only get security updates for the support period. This way, if someone has working, older hardware that may or may not be getting anymore updates (like older graphics cards), then can pin the appropriate core to stop upgrading. As long as nothing in the other cores is dependent on something newer, they can still float to newer packages. Someone could stay on a tested, stable kernel and DE if they want while still having newer applications. Someone else could stay on a lock down the display portion if there graphics card stopped being supported while letting everything else float on (until a depedency issue arises, which they would be notified about). This might help out some of the flavors as well. They would still be able to upload/break things in the devel channel (opening it up to a larger audience for testing), while people could be on the newest official release in the current channel as soon as it's ready to go. This would definitely make the infrastructure more complex, but it frees up the bigger picture of allowing the OS to be as stable or up to date as someone wants. Of course, it's just an idea and I providing it as food for thought--please tear it apart. Jon -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Regarding patching virtualbox in 12.04
2013/3/5 Chris Johnston chrisjohns...@ubuntu.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2013 11:53 AM, Pranith Kumar wrote: Hi, I am writing this regarding the issues being faced by Virtualbox users in 12.04. 12.04 was released with kernel 3.2 and then the kernel 3.5 was offered as a possible upgrade. Most users are currently switching over to 3.5 What makes it worse, is that at new installations, kernel 3.5 is the default. So this boils down to virtualbox being broken in LTS release by backport kernel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/06/2013 02:10 AM, Allison Randal wrote: On 03/05/2013 07:47 PM, Robert Bruce Park wrote: That's how I've been interpreting this all along... 2-year release cadence, and the current dev release is simply declared rolling without any real changes. I don't see any issues with this: it's a huge reduction in SRU burden while allowing more developer time to be spent developing things. I don't have a problem with a 2-year cadence either. It's a sound engineering plan. The risk comes in building up a lot of hoopla about rolling releases being a stable replacement for the 6-month cadence, not investing the resources required to really develop/support rolling releases right now, and then failing to deliver anything remotely close to the stability of the prior 6-month releases. It's better to under-promise and succeed beyond expectations, than to over-promise and appear to fail. It's easy enough to declare a 2-year cadence, and say that rolling releases are an idea we'll be working on and plan to have solid after the 14.04 release. That leaves time and space to do things right, and only announce they're ready when they really are ready. This still leaves the question of how best to support OEMs like System76, and the Flavors. But I think jonathan is on the right track with LTS + key package sets (or 13.04 + key package sets, if that's declared the final 6-month release). I can speak for some (but not all!) of the OEMs that work with Canonical to ship Ubuntu. Canonical's OEM preload business works with OEMs like Dell and HP. Those OEMs have largely shifted away from the interim releases to focus on LTS releases. For large OEMs shipping in high volume we found that the 6-month cadence doesn't align well with and was too disruptive for the OEM product lifecycle. Currently we ship 12.04.2 to our major OEM preload customers. Some observations from the big-OEM perspective: 1) The support lifecycle of the OS is important; an 18 month support lifecycle is too short for a product that may be manufactured for 3 years 2) Switching OSes in the factory is expensive and large OEMs like to do it infrequently 3) Stability is critical and the quality standards are high. Functionality like suspend/resume has to be rock-solid. To date, even the LTS releases need tweaks before they're stable enough to be delivered to OEMs. From that point of view, standardizing on the LTS releases is a clear win, and large OEMs are already pretty well insulated from the interim releases - we treat the interim releases as a series of technology previews. That said, I recognize that other OEMs like System76 and ZaReason have different goals and constraints than the big OEMs. I find that refreshing and exciting, and I hope they continue to prosper as part of Ubuntu's growing ecosystem. Steve Magoun Engineering Manager Canonical -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On Thursday, March 07, 2013 12:40:44 PM Steve Magoun wrote: ... 3) Stability is critical and the quality standards are high. Functionality like suspend/resume has to be rock-solid. To date, even the LTS releases need tweaks before they're stable enough to be delivered to OEMs. ... Have all these changes be upstreamed back to Ubuntu? 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: reflecting on first UDS session on rolling releases
On 3/7/13 3:12 AM, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bryce Harrington wrote on 06/03/13 15:45: ... He means not just the core OS but also the application ecosystem. In Windows the OS release is just the core OS, and then users manually install newer versions of whatever applications they want. As they do in Ubuntu, unless the application is in the core OS repositories. (I would argue that any software project that has their act together will have .debs for the LTS downloadable from their web site or a PPA, or even via -backports, so in practice this isn't that different. However, I believe that was the distinction he was drawing.) ... Any software project that has their act together is in MyApps. ;-) - -- mpt Many of the relevant software projects aren't apps themselves. Wine is probably a great example. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/07/2013 09:40 AM, Steve Magoun wrote: Some observations from the big-OEM perspective: 1) The support lifecycle of the OS is important; an 18 month support lifecycle is too short for a product that may be manufactured for 3 years 2) Switching OSes in the factory is expensive and large OEMs like to do it infrequently 3) Stability is critical and the quality standards are high. Functionality like suspend/resume has to be rock-solid. To date, even the LTS releases need tweaks before they're stable enough to be delivered to OEMs. From that point of view, standardizing on the LTS releases is a clear win, and large OEMs are already pretty well insulated from the interim releases - we treat the interim releases as a series of technology previews. Do you have a sense of what handset manufacturers will need, just in general terms? I know that phones/tablets were mentioned as a motivation for rolling releases. But, I haven't heard any mention so far of things like the FCC approval process. The certification requirements on what can be shipped as a phone are very, very different than those for laptops/desktops. It seems likely that the OEMs for phones will also prefer, or even be required by law, to stick to LTS + tightly controlled updates to a few specific packages. That said, I recognize that other OEMs like System76 and ZaReason have different goals and constraints than the big OEMs. I find that refreshing and exciting, and I hope they continue to prosper as part of Ubuntu's growing ecosystem. Meeting their needs is a core requirement in the choice between alternate futures. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/07/2013 02:03 PM, Allison Randal wrote: On 03/07/2013 09:40 AM, Steve Magoun wrote: Some observations from the big-OEM perspective: 1) The support lifecycle of the OS is important; an 18 month support lifecycle is too short for a product that may be manufactured for 3 years 2) Switching OSes in the factory is expensive and large OEMs like to do it infrequently 3) Stability is critical and the quality standards are high. Functionality like suspend/resume has to be rock-solid. To date, even the LTS releases need tweaks before they're stable enough to be delivered to OEMs. From that point of view, standardizing on the LTS releases is a clear win, and large OEMs are already pretty well insulated from the interim releases - we treat the interim releases as a series of technology previews. Do you have a sense of what handset manufacturers will need, just in general terms? I know that phones/tablets were mentioned as a motivation for rolling releases. But, I haven't heard any mention so far of things like the FCC approval process. The certification requirements on what can be shipped as a phone are very, very different than those for laptops/desktops. It seems likely that the OEMs for phones will also prefer, or even be required by law, to stick to LTS + tightly controlled updates to a few specific packages. I don't have much data about what the handset manufacturers need from the Ubuntu cadence. I can speculate that they're far more interested in their own dates than ours. By extension, any changes that (a) allow us to build Ubuntu in a more efficient way and (b) increase the quality/reliability/marketability of Ubuntu will improve the chances of Ubuntu in the mobile marketplace. Steve -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: reflecting on first UDS session on rolling releases
On 03/07/2013 01:15 PM, Scott Kitterman wrote: On Thursday, March 07, 2013 12:40:44 PM Steve Magoun wrote: ... 3) Stability is critical and the quality standards are high. Functionality like suspend/resume has to be rock-solid. To date, even the LTS releases need tweaks before they're stable enough to be delivered to OEMs. ... Have all these changes be upstreamed back to Ubuntu? The vast majority of the stability fixes and other changes from Canonical's enablement program are implemented directly in Ubuntu, either as Stable Release Updates or as patches applied to the currently in-development version of Ubuntu. Most of our changes go into the kernel and related plumbing for hardware enablement, but we have invested significant time in other components as well (ubiquity and unity are two examples). At any given time there are changes that are in the process of being upstreamed but have not yet hit Ubuntu or Ubuntu's upstream. One of Canonical's goals here is to avoid maintaining separate kernels or forked packages for our preload customers, so we are motivated to keep push as much upstream as possible. Steve -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Follow Up from Let's Discuss Interim Releases
Rick Spencer rick.spen...@canonical.com wrote: Hi all, There has been a lot of discussion and impact around the strawman proposal for changing our release cadence that I sent last Thursday. There was a misconception that the proposal was a decision that I was masking as a call for discussion. I want to reassure everyone that I really did mean it as a discussion. I feel passionately that we need to change and innovate in this area, but a change like this cannot succeed, or in fact be made, without discussion in the community and proper governance. Discussion of this topic on the mailing list and at UDS this week was wide ranging. There were a lot of divergent opinions and ideas. The discussion seems to have resulted in roughly three different forms of proposals. 1. Move to a rolling release similar to what I proposed in the original straw man. 2. Continue to release interim releases but only support them until roughly the next interim release 6 months later. 3. Dramatically increase the rate of our releases to, say, once per month. I've attempted to capture the essence of these proposals (and associated sub-proposals) along with a structure for points and counterpoints in wiki format to support honing and organizing. They are currently stubs, so will need detailed content and continued honing, but the wiki format invites collaboration on that honing. See: https://wiki.ubuntu.com/ReleaseCadence https://wiki.ubuntu.com/ReleaseCadence/RollingRelease https://wiki.ubuntu.com/ReleaseCadence/SixMonthInterimRelease https://wiki.ubuntu.com/ReleaseCadence/TrueMonthlyReleases I'd like to invite everyone who is interested to get their input into these pages by March 18th (or thereabouts). Then I'd like to work with interested people to select what we consider the best proposal to take to the technical board for guidance. Part of the straw man proposal was to convert 13.04 into a Rolling Release in order to allow us to go faster on the converged OS starting immediately. Given the work that is left to achieve a proper proposal for the tech board, I don't foresee such a proposal being completed in time to make such a radical change to 13.04. Maintaining the current cadence should also be one of the options. 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: Follow Up from Let's Discuss Interim Releases
On 03/07/2013 07:15 PM, Scott Kitterman wrote: Maintaining the current cadence should also be one of the options. That would be the default if no proposal was submitted to the TB or no proposal approved by the TB. Or, do you mean there's value in writing up the advantages of the current cadence in parallel to the other options, for a clearer comparison? I can see that. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Follow Up from Let's Discuss Interim Releases
On Thursday, March 07, 2013 08:01:37 PM Allison Randal wrote: On 03/07/2013 07:15 PM, Scott Kitterman wrote: Maintaining the current cadence should also be one of the options. That would be the default if no proposal was submitted to the TB or no proposal approved by the TB. Or, do you mean there's value in writing up the advantages of the current cadence in parallel to the other options, for a clearer comparison? I can see that. Yes. If options are going to be presented to the TB, stick with what we have should be one of them. 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: Follow Up from Let's Discuss Interim Releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13-03-07 07:15 PM, Scott Kitterman wrote: Rick Spencer rick.spen...@canonical.com wrote: https://wiki.ubuntu.com/ReleaseCadence/SixMonthInterimRelease Maintaining the current cadence should also be one of the options. I disagree, the current cadence (along with the current support periods and the current SRU process) is totally unsustainable. There is a *ton* of effort currently being put into supporting totally irrelevant interim releases. Staying at a six-month cadence is already one of the options, but the proposal greatly reduces maintenance burden by reducing support periods for interim releases. This allows most people to continue on with their happy status quo, while reducing the obligatory SRU nightmare for releases that nobody uses. Although I feel quite strongly about my support for the rolling release model, if it is rejected, we can't continue as we used to. We simply do not have the resources to support more than two releases at a time. I'd prefer to only have to support LTS+rolling, but LTS+one interim at a time would be an acceptable second best. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJROW5ZAAoJEMnVpoCaWglEeEMP/0nT5GIlUXNgjYRqI2gDzrJI m8Z9xVwsat46TFiVc9Xw7d/WCNUUWExqJQlo6ALOQrWOHMEV8y0vAZUOtF1ogGrI VsYVqbAvNzGfP3ToLixLnZRFKgth68Q+MggT4H0XOJh2mgV8lOBEt+Njdg4PUYZs 03Cjy49UTYcbzsmh9q1+cK8yloFdSgBfm2lhk2F0FIwVuha0IXjv4P3iHer6eDg4 dCqulFTxdIZQnGfdSKTkqVpFdF838JIUi1lbYMGrQwxEaaf/PjpJbE6tDVp8xXsP G8lZ+tT2GvBeZw3XuSu6XCo/p0LXtpwQGCOOOIj4FGRQX7h2R2l1LKNcGDm5E4Vn tksI3z26qAHPdZYEqdHkNkjg6xJdd/JdVS35bYNGbKCXdeHG9WoHlbi6SpvNX1lw mBlqks1exyoSAFBinpsJSsJPGD/7CA0vvrj7T90hqy3e0h1RirkgZx3n6beaqydh 2JT2VAocy3qpMYjx+qXtwuOi9dakPcm7B29gHu/pOAto07o6rpeop35gLTgn5GBM h2HxtliEPCoFoSl5B2UJF7hPU+q8owRH8NzY7S8pXkvl836gb+6vNUVsNC+nRfSZ SWEOiVz4gfhNbqr4iViF63/A9pLJA3imuoHaRLlxYMrl+GZE7x20HZAJK/Go9OLV 7TmKxgOZNfqieSINi5Lq =ThC8 -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Follow Up from Let's Discuss Interim Releases
On Thu, Mar 7, 2013 at 8:12 PM, Scott Kitterman ubu...@kitterman.com wrote: On Thursday, March 07, 2013 08:01:37 PM Allison Randal wrote: On 03/07/2013 07:15 PM, Scott Kitterman wrote: Maintaining the current cadence should also be one of the options. That would be the default if no proposal was submitted to the TB or no proposal approved by the TB. Or, do you mean there's value in writing up the advantages of the current cadence in parallel to the other options, for a clearer comparison? I can see that. Yes. If options are going to be presented to the TB, stick with what we have should be one of them. I presume that if there is no proposed change, there would be no proposal to take to the TB, hence leaving off the current way of working as an option. :-) Jono -- Jono Bacon Ubuntu Community Manager www.ubuntu.com / www.jonobacon.org www.identi.ca/jonobacon www.twitter.com/jonobacon -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Follow Up from Let's Discuss Interim Releases
On Thu, 7 Mar 2013, Jono Bacon wrote: I presume that if there is no proposed change, there would be no proposal to take to the TB, The status-quo has both merits and demerits. It is necessary to evaluate those as thoughly as the rest, to adequately explore the problem, and available solution space(s). Without doing that most basic of academic basework, any presumed improvement is likely to be flawed in proposition and implementation. It would be like running a study without a control group baseline to evaluate results against; or more frankly, like expecting a perfect outcome when urinating in an area of high atomspheric pressure. Thusly Jono, I respectfully disagree: the donkey work should be done. -Paul -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Raring Feature Freeze now in effect
Hello Ubuntu Developers, Notwithstanding recent discussions about possible changes to the release cycle, 2100 UTC has now passed and we are in Feature Freeze[1] for Raring. From here until 13.04, the focus of work in Raring is on fixing bugs and polishing. If you believe that a new package, a new upstream version of a package, or a new feature is needed for the release and will not introduce more problems than it fixes, please follow the Freeze Exception Process by filing bugs and subscribing ubuntu-release. https://wiki.ubuntu.com/FreezeExceptionProcess In light of the aforementioned recent discussions and the uncertainty that may have resulted, the release team plans to be lenient in enforcing the feature freeze over the next few days. If you have changes that just missed the deadline, and are concerned about the overhead of the full FFe process for these changes, feel free to come talk to us on IRC (#ubuntu-release). A reminder that next week will also be the Beta1 release for flavors that opt in to it.[2] Thanks, -- Steve Langasek on behalf of the Ubuntu Release Team [1] https://wiki.ubuntu.com/FeatureFreeze [2] https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule signature.asc Description: Digital signature -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
Why there are many discussions in ubuntu-devel recently but not here?
As title. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
