Re: reflecting on first UDS session on "rolling releases"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13-03-12 10:45 AM, Robert Collins wrote: > On 13 March 2013 05:53, Robert Bruce Park > wrote: >> Considering that Ubuntu has yet to be fully adopted by the >> mainstream, I'm pretty sure that *all of Ubuntu* skews pretty >> heavily towards early adopters, although Steam users would be >> skewed even harder. > > Mainstream *what*? > > Desktop users? Sure. Yes, I was referring to desktop users, among which we are quite the niche. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRP21vAAoJEMnVpoCaWglEP/cP/1VRtLWZCoM27SgVItHS2Hlo Zez9/fMdqgNy3mAc0AlWxwYguoNltPKQmdIjVuGAsCfe4wC1Nrq08rGr2lZQ2CUp Iml4Uy88ul+ZIsk3lzKHL54MPI/JKoe4RGXXBmOg3ByCzSmoF18jDd+hgXh5MAY0 m67j9dtpd80UcaW750bYjUOJPL48vlNsQlr6s69pbdYS/SFIUZ+ZdQYfNUFkNocl FID5OPtCxESi6jH11X1hNoYpMAJ2INXYgbfNoTRy/oIHsJj2LLUJZudvurg8MROD pmd+Z4OCnk2gRwINIj5vadi4Dfpkg3d6DU5ZwbC8R+Y3OkP5HCvpiESuqoGz6uGx Q6EYvI+9rSA24gXQVGp9UtqDQW+zy+3Ccr3/+PARS5KdQ3XjvgK1HL5R0841l9Z4 rBqCsOvzPR1DQ5GAiiXFHpU7O0nwfz4yD1DD00P4GIJp1PG5B33NcveBTAGW1PdO M40VILsUooHKgE4dGRc2ePxDCBXJ2Q+IjvpbURg3FiMtd9Hy1P48qgWYJtKgRn/b ms+hAoypOztoKjMRfftshltgqXnK5QtczZUGtM/DevFt2CWpxBGwMSQTQxnGLc5o 4nX1/5SJlLFfOomDWrwHH7FOp0Jo6GKc0j/VmVpYsOoThL6VpoSc2DUC5LIlTzXm BYtCHNTTAybvuukJXGHo =KO2x -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: Regarding patching virtualbox in 12.04
Yes, as of the users I didn refer to normal/end-users but to hackers and advanced users like me (advanced enough to know these trivial diffs). As per my experience the older version on the SW Centre is having some issues with networking on VM's which is fixed/better performing on the latest one with some other changes/fixes. Also what is missing is the addons and stuff from Virtual Box. Regards, Pranav On Tue, Mar 12, 2013 at 11:19 PM, Thomas Mashos wrote: > I don't think making the user go to the website to download the deb is a > very good idea. > > A) We shouldn't have broken software in the repo (especially when it's > known broken with a known fix) > > B) Some users can't/won't install software from third party areas/repos > and will only use the default repos (a sane and completely relevant idea) > > C) IIRC, the deb file on the virtualbox website has proprietary bits > included. The version in the repos is the OSE version. > > Thanks, > > Thomas Mashos > > > On Mon, Mar 11, 2013 at 12:57 AM, Pranav wrote: > >> I think it is better to download the Virtual Box deb file from its >> official website instead of the ubuntu ppa or software centre as its a >> older version and also the above mentioned issue will arise. >> Regards, >> Pranav >> >> >> On Wed, Mar 6, 2013 at 2:31 PM, Steffen Barszus < >> steffenbpu...@googlemail.com> wrote: >> >>> 2013/3/5 Chris Johnston : >>> > -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 >>> >> >> >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> >> > -- 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 13 March 2013 03:57, Thierry Carrez wrote: > Robert Collins wrote: > Understood. IMHO that "LTS mode" would significantly reduce the benefits > compared to the current LTS. Current LTS promises to keep > you secure with a behavior mostly unchanged. It gives you unchanged > behavior for 99% of the packages in the archive, perfect security > support for main, and best-effort-but-still-good security support for > everything else. I think that is overselling the current LTS. I would say it gives you approximately no security support for 90% of the archive. Many smaller projects don't issue CVEs when they have a defect, and the only way you have security support is if you get a new release. The SRU process is excruciatingly slow [by choice, it is an engineering tradeoff]. > It looks like to avoid turning it into a maintenance nightmare, your > "LTS mode" would have to significantly reduce the scope of supported > packages: only a very limited set of packages would both be preserving > behavior *and* be security-supported. Everything else would have to drop > one or the other (most likely deciding to abandon preserving behavior). The thing about having a user base of millions of users is that those incompatibilities become a massive force multiplier for packages used by any significant % of the user base. Folk that proxy for large user bases will naturally want to minimise the cost of accomodating such changes - and the LTS cycle allows them to reduce repeated incompatible changes to the same thing, by folding them all together. However for distinct incompatible changes, the LTS cycle only serves to bundle them together, making the time to adjust to a release larger and slower (which provides backpressure on the frequency of releases, but the further apart the releases are the greater the bundled changes it is a vicious cycle). And yet preserving behaviour over and above what upstream does is an extraordinary thing to do. Backported security fixes are work upstream didn't do, for instance. Assertion: Generally speaking upstreams expect folk to upgrade every time they release. And they are surprised and unhappy when folk don't *and* they get bug reports from users running old releases. This isn't just the web space - even old plumbing tools like gcc and automake care about this (and you can tell, *because* they talk about backward compat... if they didn't expect immediate upgrades and [transient] skewed user populations, backwards compat becomes much less important). The /normal/ thing upstreams expect is that they do a release that is compatible, with *perhaps* a small number of documented incompatabilities, and users upgrade near immediately. So I'm not suggesting more or less work, I'm suggesting that we *take the work where it belongs* - in upstream, *when* the incompatible change is being made. Old: (N incompatible changes upstream, then M backported security fixes for 5 years) per LTS New: (N would-have-been-incompatible changes enhanced to be compatible via a config option). If N is larger than 3M(*) then it is a wash. If N is < 3M, then this is clearly more efficient, and will also most folk that run trunk of such projects have an easier time. *) 3M because (LTS 2 years apart, 5 year life -> 2 LTS's, + 1 current release under Mark's 7 month support proposal) > Not saying that means this is unreasonable, just detailing how your LTS > mode differs from what LTS currently provides :) Yeah - it is good to spell it out. -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: Regarding patching virtualbox in 12.04
I don't think making the user go to the website to download the deb is a very good idea. A) We shouldn't have broken software in the repo (especially when it's known broken with a known fix) B) Some users can't/won't install software from third party areas/repos and will only use the default repos (a sane and completely relevant idea) C) IIRC, the deb file on the virtualbox website has proprietary bits included. The version in the repos is the OSE version. Thanks, Thomas Mashos On Mon, Mar 11, 2013 at 12:57 AM, Pranav wrote: > I think it is better to download the Virtual Box deb file from its > official website instead of the ubuntu ppa or software centre as its a > older version and also the above mentioned issue will arise. > Regards, > Pranav > > > On Wed, Mar 6, 2013 at 2:31 PM, Steffen Barszus < > steffenbpu...@googlemail.com> wrote: > >> 2013/3/5 Chris Johnston : >> > -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 >> > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > -- 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 12 March 2013 17:23, Phillip Susi wrote: > On 3/9/2013 6:45 AM, Otus wrote: >> >> On Fri, Mar 8, 2013 at 6:51 AM, Robert Bruce Park >> wrote: >>> >>> 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. >> >> >> If you need/wish to cut down the number of supported releases all the >> way down to two at a time (from current ~5) there are really only two >> options: > > > I am pretty sure he meant all supported LTS count as one, and the goal is to > not have more than one non LTS supported. > LTS releases must overlap to allow for upgrades. Plus the benefit of LTS is its longer support, e.g. even reaching beyond the next two LTS release. 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 Tue, Mar 12, 2013 at 5:45 PM, Robert Collins wrote: > Mainstream *what*? > > Desktop users? Sure. > Datacentre operators? We are --wy-- beyond early adopters here. > > Our user base is very varied and you have to segment it to reason > sensibly about the stats we have. At to be clear, the statistics from error reporting do not take servers into account yet. -- 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 13 March 2013 05:53, Robert Bruce Park wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 13-03-12 09:34 AM, Evan Dandrea wrote: >> I am fairly certain that the metrics from Steam skew towards early >> adopters. > > Considering that Ubuntu has yet to be fully adopted by the mainstream, > I'm pretty sure that *all of Ubuntu* skews pretty heavily towards > early adopters, although Steam users would be skewed even harder. Mainstream *what*? Desktop users? Sure. Datacentre operators? We are --wy-- beyond early adopters here. Our user base is very varied and you have to segment it to reason sensibly about the stats we have. -Ro -- 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: Regarding patching virtualbox in 12.04
I think it is better to download the Virtual Box deb file from its official website instead of the ubuntu ppa or software centre as its a older version and also the above mentioned issue will arise. Regards, Pranav On Wed, Mar 6, 2013 at 2:31 PM, Steffen Barszus < steffenbpu...@googlemail.com> wrote: > 2013/3/5 Chris Johnston : > > -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 > -- 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 3/9/2013 6:45 AM, Otus wrote: On Fri, Mar 8, 2013 at 6:51 AM, Robert Bruce Park wrote: 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. If you need/wish to cut down the number of supported releases all the way down to two at a time (from current ~5) there are really only two options: I am pretty sure he meant all supported LTS count as one, and the goal is to not have more than one non LTS supported. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: arm64 Debian/Ubuntu port image available
+++ Wookey [2013-02-27 02:10 +]: > State of the Debian/Ubuntu arm64 port > = > > *** Arm64 lives! *** > > Executive summary > - > > * There is now a bootable (raring) image to download and run > * A bit more work is needed to make the rootfs useable as a native buildd Networking and apt, and various bits of breakage was fixed shortly after the initial upload. After some jolly hacking at Connect, with much help from Doko, we got the build and install dependencies of debhelper (what a lot of crap it (recursively) needs!) crossed and uploaded, and fixed some missing perl bits, so I have now successfully built the 'hello' package with the image. It's such fun to watch configure scroll by one line at a time for about an hour Cross-building stuff: Ian Campbell also got the Xen arm64/aarch64 cross-build working for raring (not yet integrated into the packaging), using the info on https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap without too much aggravation (libyajl needed to be cross-fixed first), so the environment is already useful for building and getting stuff cross-ready, so long as you don't have too many build-deps. Feedback from anyone else who tries this is welcome. > The images are available for download: > http://wiki.debian.org/Arm64Port#Pre-built_Rootfs > Along with destructions there for making your own. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Minutes from the Ubuntu Kernel Team meeting, 2013-03-12
= Meeting Minutes = [[http://irclogs.ubuntu.com/2013/03/12/%23ubuntu-meeting.txt|IRC Log of the meeting.]] [[http://voices.canonical.com/kernelteam|Meeting minutes.]] == Agenda == [[https://wiki.ubuntu.com/KernelTeam/Meeting#Tues, 12 Mar, 2013|20130312 Meeting Agenda]] === ARM Status === R/master: nothing new this week. R/omap4: verified that pvr-omap4 doesn't work with our multiplatform 3.8 kernel, i'm waiting input if we can drop the omap4 dekstop image. R/nexus7: ported overlayfs from P (lp1076317) - awaiting testing from a brave soul since my nexus7 is borked ATM (lp1126836). === Release Metrics and Incoming Bugs === Release metrics and incoming bug data can be reviewed at the following link: * http://people.canonical.com/~kernel/reports/kt-meeting.txt === Milestone Targeted Work Items === || apw || hardware-r-kernel-config-review || 1 work item || || || hardware-r-delta-review || 3 work items || || || foundations-r-secure-boot || 1 work item || || || foundations-r-aarch64 || 1 work item || || || foundations-r-upstart-user-session-enhancements || 1 work item || || ogasawara || hardware-r-kernel-config-review || 3 work items || || || hardware-r-kernel-version-and-flavors || 2 work items || || || hardware-r-arm-kernel-maintenance || 1 work item || || || hardware-r-kernel-misc|| 1 work item || || ppisati || hardware-r-kernel-config-review || 1 work item || || rtg || hardware-r-delta-review || 1 work item || The above summarizes the remaining work items owned by individuals on our team for the rest of the 13.04 cycle. === Status: Raring Development Kernel === Since our last meeting 2 weeks ago, we have rebased to the latest v3.8.2 upstream stable kernel. We've also added Haswell ULT NFC, I2C, SPI, and SATA RTD3 support, USB3 port power off capability, prime support for nouveau and radeon, and other misc config updates and bug fixes. Important upcoming dates: * Raring: * Thurs Mar 21 - 13.04 Final Beta Freeze (~2 weeks) * Thurs Mar 28 - 13.04 Final Beta Release (~3 weeks) === Status: CVE's === == 2013-03-12 (weekly) == Currently we have 46 CVEs on our radar, with 10 CVEs added and 1 CVE retired this week. See the CVE matrix for the current list: * http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html Overall the backlog has decreased slightly this week: * http://people.canonical.com/~kernel/status/cve-metrics.txt * http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt === Status: Stable, Security, and Bugfix Kernel Updates - Quantal/Precise/Oneiric/Lucid/Hardy === Status for the main kernels, until tiday (Feb. 26): * Hardy - Nothing this cycle * Lucid - In Prep; (2 commits) * Oneiric - In Prep; 4 upstream releases; (68 commits) * Precise - In Prep; 2 upstream releases; (197 commits) * Quantal - In Prep; 2 upstream releases; (175 commits) Due to a regression, the Quantal kernel and it's derivatives have been respun. Current opened tracking bugs details: * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html For SRUs, SRU report is a good source of information: * http://people.canonical.com/~kernel/reports/sru-report.html Future stable cadence cycles: * https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock (bjf> >) (bjf> >) Note: The week of March 21 is the week the last Hardy and Oneiric kernels may be built. (bjf> >) === Open Discussion or Questions? Raise your hand to be recognized === Welcome back to the Kernel team, kamal! -- 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 On 13-03-12 09:34 AM, Evan Dandrea wrote: > I am fairly certain that the metrics from Steam skew towards early > adopters. Considering that Ubuntu has yet to be fully adopted by the mainstream, I'm pretty sure that *all of Ubuntu* skews pretty heavily towards early adopters, although Steam users would be skewed even harder. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRP11xAAoJEMnVpoCaWglECkUP/iX2tIHpaxX0iKApoASWzL4t /K78DD+94Bc5neV+DDAkmKWjqY/t3Xv3xJgFyXmbzHHp09m7nQhlmGFamyo7irbs Igg/85Ey5/qRQevDaV8H4U71VDAC1qFtGFF+hIyBsiMkWAVqTiqKBUwPTPXk9Rb+ CKrMmV1CkoXGFSs0zMlF6sT99VVrmvtxA95Pwy4A61RNXMGRGBUCvAPOyQXyvCU6 lYLwdTjAr1KM9MGFPAu6yG6E5lySyAu5tbXGRJZzgrFGyZfjPHDnczjWPv4mquaS e1YGbMMextNgwuhrVf4C2orFLQOFvkgI9k35OykIW6rLR/ypLC1ADy0kzUW0mmX8 gYWwl4pEqSkS2pC1OQfQPB1SKxefJ+FSdcbFyy/akCgY7pzybvR9tCN8ir1UWfRg Iar1nrY+3cDGaH5VKDF7EzRxq9r16X4CAhZo2UymOkWJ6CMyK0xlinJEAFVU/9nT ZAtjneAJixTa2ZUHngTbVw9tS67PoUMWkB/cnFlgy/HB35BInYsBPLpO1v89tndL ILzZ4TRyLZF6vkOWAiFy+et9ezM/8jUL6b8Tno4JVgmirw/tBZPoxl0NKXF4QMrP krxA5WXTACuIAw0p8vP0VaWtmntvy2iR5N1yUE40XRq4cBU4Lcwz94j1D+Pntpgm XLbsANkfBRAwW29BWsik =m56W -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
Announcing the Ubuntu SDK Days
Hello everybody, Hot on the heels of the announcements of the Ubuntu SDK and the Touch Developer Preview, we bring you the first ever Ubuntu SDK Days. On Thursday, 14th March and Friday, 15th March a number of app developers and Ubuntu SDK creators will get you started writing apps for Ubuntu on multiple devices. It's surprisingly simple, and since the announcement we've seen many early adopters try out the SDK and the first apps up and running. We will answer your questions, talk about best practises and show you the power of the SDK. Here a quick overview over the sessions we'll run: Installing and Configuring the SDK Writing your first app with the SDK Writing games with QML and Javascript Live update from the development progress of the Touch Core Apps Several Q&A sessions Making the best of the Ubuntu App Design guidelines More about the SDK skunkworks projects Introducing Friends and Gwibber QML Writing a new generation of Scopes Lightning talks and Project demos How to join Participating is easy: just head to http://ubuntuonair.com to watch the sessions on the schedule. Videos will be available after the event, to ensure you can watch the content even if you couldn't make it to the session you wanted. Check out https://wiki.ubuntu.com/UbuntuSDKDays/ to see the timetable of the event, be there for lots of fun and bring your friends - and your questions too! Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging Stay up to date: follow @ubuntudev on identi.ca/twitter.com/facebook.com -- 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 Mon, Mar 11, 2013 at 1:31 AM, Jason Taylor wrote: > Steam has released there OS Stats which probably has some bearing here > > 0.62% on 12.04.* LTS and 1.7% on 12.10 so over double the users are not > using the LTS > > No doubt that skews towards home users over business users I am fairly certain that the metrics from Steam skew towards early adopters. In a separate thread, Matthew used statistics from error reporting. I believe these paint a much more balanced picture (but are not without their own set of issues): "Right now, of PCs running Ubuntu 12.04 or later, 54.6 % are running 12.04 LTS, 44.9 % are running 12.10, and 0.5 % are running R." -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report
Needs info: * [totem] ask for a reproduce case for http://pad.lv/1100937 (it was added, will follow up now) Uploaded: * [appmenu-gtk.debdiff] unsubscribe http://pad.lv/780602 , already sponsored * [db5.3] sponsor http://pad.lv/1126392 * [pam] sponsor http://pad.lv/1126404 * [gnome-power-manager] sponsor https://code.launchpad.net/~dedunumax/ubuntu/raring/gnome-power-manager/bug-923292 * [tcl8.5 & tcltk-defaults] multi-arch https://bugs.launchpad.net/ubuntu/+source/tcl8.5/+bug/1122120 (plus fix defaults fallout) * [ureadahead] https://code.launchpad.net/~fehwalker/ubuntu/raring/ureadahead/fix-559525-1131404 Please reject: https://code.launchpad.net/~vibhavp/ubuntu/raring/guile-2.0/gnulib-gets/+merge/151342 not needed with current new upstream release. 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: Timescale on QMl-ification of Ubuntu Desktop
On 12 March 2013 14:25, Chris Wilson wrote: > I was wondering how long it will likely take to move the QML versions of > Unity and the Core Apps to the desktop? If the existing selection of apps > are due to be replaced, then I'm wondering how worthwhile it is to continue > are work on them. > At the moment, the plan currently targets to have unity on mir by 14.04. There is a target/priority to write core apps with the touch interface for mobile and tablet sizes. I'm speculating that some, but not all core desktop apps will transition to qml. I'm not sure what's the status of the desktop qml components is at the moment. That means it is worthwhile to continue to work on existing stack of core apps for the next 2 - 6 years (current support cycles + support cycle of the next lts if a given app stays as it is). Which is a stable and large enough timeline, that anything could change in between =) 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: Follow Up from "Let's Discuss Interim Releases"
Robert Collins wrote:
> On 12 March 2013 23:07, Thierry Carrez wrote:
>> I'm not sure I understand how this "configuration" would work,
>> especially with security updates. I'm probably missing something, so
>> let's have an example. Let's say I install "Ubuntu" on January 1st, 2014
>> and set it to "LTS mode". I get Gnucash 2.5. Alice does the same on
>> February 1st, 2014 and grabs Gnucash 2.6. Bob does the same on March
>> 1st, 2014, gets Gnucash 3.0, which introduces a very large behavior
>> change. In May, a vulnerability is discovered that affects all versions
>> up to 3.0.1. The security team has to backport the fix to 2.{5,6} and
>> 3.0 because all those LTS users expectation is that they will get "keep
>> me secure with my behavior unchanged" mode ?
>
> So, if gnucash is supported - that is, if its part of the APIs and
> behaviour we have *committed* to preserving, that 3.0 upload wouldn't
> happen *until* we had figured out how to preserve behaviour for the
> users that had started on 2.x.
>
> If gnucash isn't supported, if its just in universe, then the security
> team isn't on the hook, and we would just have uploaded 3.0.1 with the
> fix.
>
> So lets assume it is supported: There are two broad avenues to
> preserving the behaviour it had with the 3.0 introduction.
> a) versioned installs. We do a little transition dance and end up with
> gnucash2 and gnucash as separate packages. In this approach nearly no,
> or even no code changes are needed to gnucash, but we pay a
> maintenance cost indefinitely.
> b) feature flags. We (or upstream) restore (or keep in the first place
> - much easier to do it that way) the 2.x behaviour when this 'large
> change' is coming in 3. The default is the latest upstream behaviour,
> but a user/system wide config can easily tell gnucash to revert to the
> 2.x behaviour. In this approach we only have one package, and we just
> update it with the security release.
Understood. IMHO that "LTS mode" would significantly reduce the benefits
compared to the current LTS. Current LTS promises to keep
you secure with a behavior mostly unchanged. It gives you unchanged
behavior for 99% of the packages in the archive, perfect security
support for main, and best-effort-but-still-good security support for
everything else.
It looks like to avoid turning it into a maintenance nightmare, your
"LTS mode" would have to significantly reduce the scope of supported
packages: only a very limited set of packages would both be preserving
behavior *and* be security-supported. Everything else would have to drop
one or the other (most likely deciding to abandon preserving behavior).
Not saying that means this is unreasonable, just detailing how your LTS
mode differs from what LTS currently provides :)
--
Thierry Carrez (ttx)
Ubuntu core developer
--
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"
Steam has released there OS Stats which probably has some bearing here 0.62% on 12.04.* LTS and 1.7% on 12.10 so over double the users are not using the LTS No doubt that skews towards home users over business users The real news is steam has done what ubuntu can't do, they are supporting all there linux games at the "most recent version" across 2 releases. That's the real issue, trim main to sys only with fixed point release and rolling release user level apps Cheers -- "Weekends don't count unless you spend them doing something completely pointless. " - Calven -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Timescale on QMl-ification of Ubuntu Desktop
I was wondering how long it will likely take to move the QML versions of Unity and the Core Apps to the desktop? If the existing selection of apps are due to be replaced, then I'm wondering how worthwhile it is to continue are work on them. Chris -- 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 Fri, Mar 8, 2013 at 6:51 AM, Robert Bruce Park wrote: > 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. If you need/wish to cut down the number of supported releases all the way down to two at a time (from current ~5) there are really only two options: 1. Cut LTS support from 5 to 4 years, do not offer support for the rolling dev version. 2. Cut LTS support from 5 to ~2 years, support a single release (rolling or non-LTS) in addition. Either way the LTS release, which OEMs and (some) ISVs presumably depend on, would need a shorter support period. Two years of LTS support seems completely untenable, so that only really leaves one path forward, if two releases are indeed the maximum that can be supported. It comes down to simply cutting all non-LTS releases and shaving a year off LTS support. -- 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 12 March 2013 23:07, Thierry Carrez wrote:
> I'm not saying you can't use dailies to care for "getting an install
> media". You were listing what, technically, a release means today. I'm
> just saying that as of today, "releases" also mean a reference install
> media.
Ack.
> I'm not sure I understand how this "configuration" would work,
> especially with security updates. I'm probably missing something, so
> let's have an example. Let's say I install "Ubuntu" on January 1st, 2014
> and set it to "LTS mode". I get Gnucash 2.5. Alice does the same on
> February 1st, 2014 and grabs Gnucash 2.6. Bob does the same on March
> 1st, 2014, gets Gnucash 3.0, which introduces a very large behavior
> change. In May, a vulnerability is discovered that affects all versions
> up to 3.0.1. The security team has to backport the fix to 2.{5,6} and
> 3.0 because all those LTS users expectation is that they will get "keep
> me secure with my behavior unchanged" mode ?
So, if gnucash is supported - that is, if its part of the APIs and
behaviour we have *committed* to preserving, that 3.0 upload wouldn't
happen *until* we had figured out how to preserve behaviour for the
users that had started on 2.x.
If gnucash isn't supported, if its just in universe, then the security
team isn't on the hook, and we would just have uploaded 3.0.1 with the
fix.
So lets assume it is supported: There are two broad avenues to
preserving the behaviour it had with the 3.0 introduction.
a) versioned installs. We do a little transition dance and end up with
gnucash2 and gnucash as separate packages. In this approach nearly no,
or even no code changes are needed to gnucash, but we pay a
maintenance cost indefinitely.
b) feature flags. We (or upstream) restore (or keep in the first place
- much easier to do it that way) the 2.x behaviour when this 'large
change' is coming in 3. The default is the latest upstream behaviour,
but a user/system wide config can easily tell gnucash to revert to the
2.x behaviour. In this approach we only have one package, and we just
update it with the security release.
> Or are you saying that Gnucash 3.0, like all other packages in the
> archive, should have a config option that says compatibility=2.x that
> would preserve any past behavior, letting the security team happily only
> patch Gnucash 3.0 ?
Not *all other packages*. *all packages that are supported*. There is
a hugely long tail of packages. It doesn't make sense to me that we
pay an overhead premium to provide no-regression behaviour on packages
used by 0.01% of the userbase. Such users can band together and
request that we provide no-regression behaviour in a few ways: they
can contribute the fixes themselves to upstream; they can contribute
them to us, or they can hire a proxy to do that.
Providing totally seamless behaviour across versions isn't /hard/ - it
is straight forward engineering most of the time, the real issue is
deciding that:
- it is worth doing
- who is going to do it.
>> I don't understand what you mean by 'point in time' here. Could you
>> expand on that?
>
> I mean keeping the association between a name and a period in time.
> "Raring is the development cycle that started in November 2013 and ends
> in April 2014".
>
> Then you can anchor a number of things to that artificial "rhythm" you
> created: sets of API versions for your API deprecation policy, reference
> install media if you still want them, common community development
> cycle, etc.
Sure, thanks for clarifying. I was thinking database PITR, which is a
very different thing :).
> My point is that there is value in having a cadence, and the cost of
> special-casing a few dates is not that high to pay.
It depends a *great* deal on the implications of that special casing.
LEAN teaches that your cycle time - the time it takes do your
plan-execute-learn-plan loop is the big definer for your agility -
your ability to respond to changing needs from your users. 6 months is
a very long interval for responding in a software project delivering
products for the cloud. 4-6 weeks would be a much better interval, I
think. But thats a different discussion :).
-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: Follow Up from "Let's Discuss Interim Releases"
Robert Collins wrote:
> On 11 March 2013 23:12, Thierry Carrez wrote:
>> Robert Collins wrote:
>
>>> A - an archive that we place a high friction change process on,
>>> intended to eliminate regressions [the SRU]
>>> B - a logical name that users can associate with a /large/ bundle of
>>> changes. One can say 'Unity in Raring is fantastic' only because
>>> Raring is a thing.
>>> C - A set of APIs that work well together and which we commit to keep
>>> working for the duration of the release (except where it is infeasible
>>> [e.g. due to facebook dropping their support for the server side of an
>>> API].
>>> D - A mostly unchanging environment. No surprises.
>>> [...]
>>
>> Today, it's also [E] an install media.
>
> I don't agree here. There is [E] an install media in the 'what is a
> release', but 'has unchanging install media' is not an important thing
> in any user story I have seen so far. Dailies *from the released
> archive* are fine *today*, if we chose to publish them. AFAICT there
> are no use cases or user expectations to fail that are tied to how
> often install media are updated vs the already covered aspects.
I'm not saying you can't use dailies to care for "getting an install
media". You were listing what, technically, a release means today. I'm
just saying that as of today, "releases" also mean a reference install
media.
>> About LTS mode ('keep my behaviour unchanged') I suspect every n years
>> you'll have to create another LTS mode. For people who want their
>> behaviour unchanged but from a reasonably modern starting point. How do
>> you handle that ?
>
> It is just a combination of options - feature flag values, so you
> could name each LTS combination 'precise' etc.
>
> Or you could take a less orchestrated approach and just allow saying
> 'give me the default behaviour new installs had on '. Then
> deprecation of support for a given thing is directly tied into that,
> and the UI can show people who are lagging warnings without needing to
> translate codenames.
I'm not sure I understand how this "configuration" would work,
especially with security updates. I'm probably missing something, so
let's have an example. Let's say I install "Ubuntu" on January 1st, 2014
and set it to "LTS mode". I get Gnucash 2.5. Alice does the same on
February 1st, 2014 and grabs Gnucash 2.6. Bob does the same on March
1st, 2014, gets Gnucash 3.0, which introduces a very large behavior
change. In May, a vulnerability is discovered that affects all versions
up to 3.0.1. The security team has to backport the fix to 2.{5,6} and
3.0 because all those LTS users expectation is that they will get "keep
me secure with my behavior unchanged" mode ?
Or are you saying that Gnucash 3.0, like all other packages in the
archive, should have a config option that says compatibility=2.x that
would preserve any past behavior, letting the security team happily only
patch Gnucash 3.0 ?
>> With a well-oiled release process, the cost is not high. And keeping
>> that logical name to describe a point in time has benefits: reference
>> install media, time-based cycle to focus development community, media
>> attention, LTS mode starting point, easy way to describe a set of APIs
>> and everything else you have in [B] above.
>>
>> If you think of a "release" not in term of upgrade and maintenance but
>> in terms of a development milestone and a breathing rhythm, I think the
>> benefits outweigh the costs. And it's certainly compatible with the rest
>> of your proposal.
>
> I don't understand what you mean by 'point in time' here. Could you
> expand on that?
I mean keeping the association between a name and a period in time.
"Raring is the development cycle that started in November 2013 and ends
in April 2014".
Then you can anchor a number of things to that artificial "rhythm" you
created: sets of API versions for your API deprecation policy, reference
install media if you still want them, common community development
cycle, etc.
My point is that there is value in having a cadence, and the cost of
special-casing a few dates is not that high to pay.
--
Thierry Carrez (ttx)
Ubuntu core developer
--
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"
> Clint Byrum writes: > I actually think this is already how many server/cloud users use Ubuntu > right now anyway. Run the LTS as your core, encapsulate your custom apps > in containers/virtualenvs/rvms/etc. Indeed. And this goes both ways: you can run a precise container on raring as well as a raring container on precise. Can we make this smooth enough that an app developer can ship a precise version on raring to enjoy API stability in the container while still running on newer versions until the newer LTS can be targeted directly ? Or instead, deliver raring containers for precise with more testing. Will it be simpler for app devs than just targeting all releases in a PPA ? Both probably apply to different workflows/team sizes. The same issue remains though, who test what ? To me, the real question is identifying the various testing populations and relate them to each release, whether you use a dev release or an LTS with additional PPAs or not is directly related to the amount of testing received/expected/accepted. After releasing bazaar for some years, I encountered a weird conclusion: whoever uses bazaar (across all releases) is really running a revision that was the tip of the trunk. Bug fixes on stable releases have been minor. In the end, I wasn't testing before releasing, I was releasing what has already been tested (across releases thanks for CI). I perfectly realize that one package is not an OS, but there are some similarities. For any software, whatever is released *has* been tested. The question is: how does that relate to me ? How close from my use cases/hardware were those tests ? What this really means, IMHO, is that the "back of the crowd" attitude, while understandable (and accepted) is just waiting to see if others die in flames, but most of the time, they just dive happily in the water (getting fresher and more fish ;). Nevertheless, +1 on btrfs to rollback a broken upgrade ;) Vincent -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
