Re: [Ubuntu-phone] ANN: TRAINCON-0 - CITRAIN all stop starting Friday
On Fri, Mar 21, 2014 at 9:17 AM, Oliver Grawert wrote: > hi, > > > I was suggesting 1.) for this special case. Get out one image that > contains the issue, let users know that it is there and block further > promotion of images until we have a fix for the root cause (but keep > landings going (and images green indeed) so we don't produce a to large > backlog). > > This should give the rest of the distro the freedom to move on with beta > preparation. > > Indeed we need to make clear that this exception is only done because we > are in a special situation currently. > If we do this, I think we should wait until upstream confirms that the bug is, in fact, upstream, and use their analysis for input in how to proceed. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: XMir update for Ubuntu 13.10
Hi Ryein, For what it's worth, I don't see it as an either or. There is one Ubuntu platform that will support everything from mobile phones, to tablets, to netbooks, to laptops, to work stations, to servers, to clouds, to instances running workloads in those clouds. Currently, we are playing catch up on phones and tablets, but the goal remains full convergence, full support for all of these from a single code base. In no way is there less of a commitment to desktop users and the integration that you mentioned, we just haven't reached the point where we can really start that integration. I'm sure we'll have some really good discussions about how to get from here to there at the next UDS, but I hope that sheds some light on the overall goal and the concern you expressed. Cheers, Rick On Tue, Oct 1, 2013 at 7:53 PM, Ryein C. Goddard wrote: > I think this is what everyone was afraid of when the Ubuntu community > decided mobile was the target platform. We are already starting to see > the desktop lag behind mobile instead of them being integrated. > > Keep up the good work, but maybe you could shed some light on my > concern? > > On Tue 01 Oct 2013 03:21:33 PM PDT, Oliver Ries wrote: > > Hi Everyone, > > > > As many of you will know, the Mir team had two core goals for the > > Ubuntu 13.10 cycle: > > > > 1. Deliver Mir + XMir + Unity 7 on the desktop for those cards that > > supported it, and fall back to X for those that don’t. > > 2. Deliver a native Mir + Unity 8 running on Ubuntu Touch images and > > devices. > > > > Unfortunately, due to some outstanding technical difficulties, we can > > only achieve the latter of these two goals. > > > > While we are on track to successfully deliver Mir for Ubuntu on > > smartphones, we are unfortunately not going to be able to deliver Mir > > + XMir + Unity 7 as the default experience on the desktop. > > > > Mir has made tremendous progress and is currently available on the > > Ubuntu archive for use, but there are still some outstanding quality > > issues that we want to resolve before we feel comfortable turning it > > on by default. Many of these issues live in the XMir part of the > > stack, which provides the integration between the X server and the > > underlying Mir system compositor. More specifically, the multi-monitor > > support in XMir is working, but not to the extend we'd like to see it > > for all of our users. The core of Mir is working reliable, but with > > XMir being a key component for our 13.10 goals, we didn’t want to > > compromise overall Ubuntu quality by shipping it. > > > > Mir & XMir are available from the archive as an optional > > configuration, but XMir won't be part of the default configuration. > > > > I know many of you have been curious about the progress of discussions > > with GPU manufacturers about Mir support, and while those > > conversations are under NDA, I can assure you they are progressing > > forward. > > > > We have compiled a Q&A which can be found > > at https://wiki.ubuntu.com/Mir/13.10/NoDefaultQ%26A > > > > If you have any further queries, please feel free to reach out to me > > or my team, and feel free to discuss this in more detail either here > > or on mir-devel (https://lists.ubuntu.com/archives/mir-devel/). > > > > best, > > Olli > > > > > > -- > 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: vUDS Scheduling
For Ubuntu touch, at least, there is a lot to figure out and do before shipping 13.10. Personally, I think it would be most beneficial to do that planning and have those discussions transparently and in an organized manner. Cheers, Rick On Mon, Aug 19, 2013 at 11:58 AM, Scott Kitterman wrote: > On Monday, August 19, 2013 10:52:18 Ted Gould wrote: >> On Mon, 2013-08-19 at 10:05 -0400, Michael Hall wrote: >> > UDS August 2013 >> > Starts: Tue, 27 Aug 2013 14:00:00 UTC >> > Ends: Thu, 29 Aug 2013 20:00:00 UTC >> >> Are we putting vUDS the three days before feature freeze? >> >> https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule >> >> Seems like bad time for people working on Ubuntu. > > I think that is generically true for the mid-cycle vUDS. This is no doubt > worse than it might be, but it's a bit early to start planning the next Ubuntu > release cycle. Whoever it's for, I don't think it's for people working on > 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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Fri, Jun 14, 2013 at 9:14 AM, Scott Kitterman wrote: > > Kubuntu has always relied on the infrastructure provided in the Ubuntu archive > to build our KDE variant on top of. It's pretty obvious to me that, at some > point, this will no longer be feasible. The Kubuntu team certainly doesn't > have the manpower or expertise to maintain their own X/Wayland stack. If Kubuntu (or any other flavor) can no longer be a *buntu flavor, I think everyone would all consider this an unacceptable outcome for the Mir project. Thanks to Jonathon and Scott for engaging in a constructive conversation about their requirements. I am confident that a mutual agreeable resolution to the technical issues will be released. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Ubuntu-phone] Status of 100 scopes and touch landing to saucy
\o/ On Fri, Jun 7, 2013 at 6:46 AM, Didier Roche wrote: > Le 06/06/2013 18:59, Didier Roche a écrit : > > > Hopefully the latest report before telling "it's in saucy now". > > > "It's in saucy now". \o/ > > When you will read those lines, the 100 scopes, unity 7 and a big chunk of > the touch port is in saucy! Please note that most of components of the touch > parts remains in universe. > > During the night, grabbing the latest fixes for Unity 7, however, we got > some intrusives commits with it and had to revert them (basically, bad > reconnection with unity-panel-service if it crashed and some big refactoring > which made unity segfaulting a lot). The good news is that the automated > tests caught that and we had to go the revert way to find the culprits. No > harm was done in this revert, but maybe some baguette has been eaten ;) > > That with some NEWing and promotions to main (with some adjustments upload), > saucy now gets all those latest goodness. > > For the stats fan, here are some involved in this transition: > 85 uploads to the archive was involved (83 by daily release) > 36 NEW components (28 for main, 16 in universe). > 38 components MIRed and promoted to main. > 1 demotion to universe > 3 packages removed from distro (old lenses replaced or not compatible with > 100 scopes). > > Note that 3 are rejected (mainly the touch apps) as they need some license > fix before entering the archive. > We noticed some remarks for our upstreams of things that would be good to > fix packaging-wise (most of them were not blockers apart from the 3 previous > mentioned components). Sebastien and I, while reviewing for NEWing them, > made some notes available here: http://paste.ubuntu.com/5741741/. The > ubuntu-unity integration team will as well help to get excellent package > standard as well, fixing those. > > So, we are resuming to normal daily release plan (but now to saucy) apart > for the apps stack so that upstream can fix (without any other tentative > upload to archive) the licensing. This one will be in manual publication > mode, meaning that we will still have package uploaded to the daily build > ppa and tests running. Just no publication to the archive. > > Thanks to everyone involved in the landing and upstream for helping fixing > promptly the issues we noticed! > > Happy upgrade :) > > Cheers, > Didier > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-ph...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Intention to drop Wubi from 13.04 release
On Mon, Apr 1, 2013 at 2:20 PM, Dmitrijs Ledkovs wrote: > On 1 April 2013 20:59, Steve Langasek wrote: > > > > I am therefore proposing to drop Wubi from the 13.04 release, starting > > immediately with the upcoming Beta. This will save our testers from > > spending their time testing an image that will not have developers > working > > on fixing the bugs they find, and spares our users from using an image > for > > 13.04 that is not up to Ubuntu's standards of quality. > > > > In terms of migration plan, we currently advertise Wubi on ubuntu.com > website [1] leading to [2]. > > I would propose to recommend people to use dual-boot install (but that > two at the moment is not flawless with windows 8). > > But if users still want the "don't change my computer experience" > maybe we should start recommending for those users to try ubuntu in a > Virtual Machine instead? > I think it should rather recommend trying a live session. They can do this from a DVD or from a USB key. Cheers, Rick -- 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"
As others pointed out "no change" is the default choice. However, if someone wants to capture our current release cadence and support model to the wiki, I don't see why there would be any objection to that. Cheers, Rick On Thu, Mar 7, 2013 at 7:15 PM, Scott Kitterman wrote: > Rick Spencer 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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Follow Up from "Let's Discuss Interim Releases"
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. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Avoiding fragmentation with a rolling release
Hi mpt, A lot of points in here. Some follow up thoughts ... On Thu, Feb 28, 2013 at 12:14 PM, Matthew Paul Thomas wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > The six-monthly Ubuntu release cycle is exciting for Ubuntu fans, KDE > fans, and (lesserly) Gnome fans ... and awful for pretty much everyone > else. > > It's awful for first-time users trying to choose a version, for ISVs, > for OEMs and ODMs, for people who write and run training programs, for > Ubuntu-related book authors, publishers, and sellers, for people > providing tech support, and for Ubuntu developers themselves trying to > release features in a finished state. Little wonder that some of those > groups ignore non-LTS releases altogether. > > So, I'm all in favor of having two-yearly releases. But for the same > reasons as six-monthly releases are bad, monthly snapshots and/or a > rolling release would be much worse -- unless we are careful to > communicate that they are for contributors only, not for end users or > ISVs. > I would put "enthusiasts" in the category of potential users. There are people who will set the dial to much fresher software if they can, even if it comes with costs and even if they don't consider themselves "contributors". > Rick Spencer wrote on 28/02/13 15:31: > > > * As Scott James Remnant pointed out some time ago, the six month > > cadence causes features to be either rushed, or to have to wait > > for six months to be released (along with other problems). > > (http://netsplit.com/2011/09/08/new-ubuntu-release-process/) > > LTS-only releases would not solve that problem, but they would reduce > the problem by about 75 percent (three releases out of four). > > Less time spent on the release process itself would also allow > more time for actual development. But on the other hand, the urge to get > features and other major changes into an LTS would be even more > frantic and rule-bending than it is for every release now. There would > be no post-LTS interim release as a consolation prize, and two years > is a long wait. > I agree this is a risk that we need to carefully managed. We already have faced this with every LTS, in fact. I am not certain that changing to a rolling releases changes the dynamic much, but the next *big* release is 2 years away could cause some additional pressure that we we'll need to take extra steps to guard against. > > > ... > > > > More clearly, I think we should: > > > > * Stop making interim releases. > > > > * Keep doing daily quality and keep improving our daily quality. > > > > * Take a monthly snapshot of the development release, which we > > support only until the next snapshot > > For software, the word "support" is incurably vague and best avoided. > What do you mean? Security updates? Backports? Tech support from > Canonical? A section on help.ubuntu.com? A listing on > friendly.ubuntu.com? Repackaging of commercial applications in Ubuntu > Software Center? > In this context "support" refers to security support and possible fixing the gravest issues. > > I don't understand why you are proposing monthly snapshots at all. Can > you elaborate? > The monthly snapshots would be for users who want the fresh software, but don't want to manage the daily grind of updating to ensure that their system is secure. The way I think of it is that we "support" 2 cadences for updates, daily and monthly. > > > > A download page that offers a choice between the LTS and a rolling > release would be exactly as horrid as one that offers the choice > between the LTS and a six-monthly release. > I would expect the stock download page to *only* point to the last LTS. > > ... > > > > == Because we Can == > > > > Daily Quality means that developers can ensure their components are > > stable and useful before they upload, and our processes protect us > > from most mistakes these days. The result is that 13.04 has been as > > robust a release over the last many weeks as 12.10 was when we > > delivered. We have achieved rolling release quality in our > > development practices, so we can capitalize on this capability > > now. > > Comparing with 12.10 is an easy target: 12.10, even after hundreds of > SRUs, is roughly 20 to 40 percent crashier than 12.04. > > Even then, your statement is true only if you change "the last many > weeks" to "yesterday". It was only yesterday that R's error rate came > close to 12.10's -- for both, about 0.07 errors per reporting machine > per calendar day. For most of the past month, R has been much > crashi
Re: Let's Discuss Interim Releases (and a Rolling Release)
On Thu, Feb 28, 2013 at 11:17 AM, Allison Randal wrote: > On 02/28/2013 07:31 AM, Rick Spencer wrote: > > > > To succeed at this we will need both velocity and agility. Therefore, I > > am starting a discussion about dropping non-LTS releases and move to a > > rolling release plus LTS releases right now. > > Hi Rick, > > At the moment, this proposal sounds mostly like a handwavey "Do less > work and get better results. Yay!" I do understand that you're more of a > traditional manager than a developer, so I'll give it the benefit of the > doubt and assume you just haven't explained it very well. Could we have > some developers explain how this model might work, in real-world > engineering terms? > The daily quality parts are well documented in blueprints from the last several UDSs and we are running them. For handling monthly releases, there is a proposal on how to do that: https://blueprints.launchpad.net/ubuntu/+spec/release-r-monthly-snapshots Otherwise, it's mostly a matter of stopping doing things. > > I'm not entirely opposed to the idea that the Debian development model > of 2-year "stable" releases with an ongoing "unstable" archive has been > right all along. But frankly, if someone came to me with this proposal > you've posted as a "startup" and asked me to invest in it, I'd say "You > haven't demonstrated that this is technically feasible." and kick them > back to the drawing board. > Oh? I would point to our last several years of improving Daily Quality and at Raring as it is today. I think our track record for making a highly usable development release is quite excellent. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
ftr, I didn't mean Friday the 27th, I mean Friday the 1st, tomorrow ;) On Thu, Feb 28, 2013 at 7:31 AM, Rick Spencer wrote: > = tl;dr = > Ubuntu has an amazing opportunity in the next 7-8 months to deliver a > Phone OS that will be widely adopted by users and industry while also > putting into place the foundation for a truly converged OS. > > To succeed at this we will need both velocity and agility. Therefore, I am > starting a discussion about dropping non-LTS releases and move to a rolling > release plus LTS releases right now. > > = Role of the LTS Releases = > Many users prefer their OS does not change very often. We have a great > system in place for these users. Every 2 years Ubuntu release an LTS and > users can ride that LTS for the whole support period. Since the LTS comes > out every 2 years, they can set a 2 year cadence of updates if they want to > stay "up to date" with LTS releases. I think this 2 year cadence works out > very well for these users. So, this proposal maintains those LTS releases > as anchors for those users. > > = Role of the Interim Releases = > But what about the 3 releases we do every six months in between (what I > call the "interim releases")? Who are they for? Why do we invest so much in > supporting multiple interim releases at a time? > > I think the value of the interim releases has run its course: > * Customers (people who pay Canonical and others to support Ubuntu) like > OEMs and Enterprises have all adopted an LTS to LTS cadence. > * Many community members recommend only LTS releases to new users because > of its longevity and stability, but the interim releases cause confusion > about what is the “right” version for someone to install. > * As Scott James Remnant pointed out some time ago, the six month cadence > causes features to be either rushed, or to have to wait for six months to > be released (along with other problems). ( > http://netsplit.com/2011/09/08/new-ubuntu-release-process/) > * Due to Daily Quality efforts, the development release is now usable > every day, so enthusiasts and community members don’t have to wait for a > stable release to get the latest software and can participate more fully in > the development of Ubuntu > * Supporting interim releases is a costly distraction from future > development, a cost in both time and attention. > > = Ubuntu NG = > In the meantime, with Ubuntu Touch, the Phone, the Tablet, and convergence > of these device experiences with the Desktop, we are in the process of > inventing what is essentially a next generation Ubuntu. There will be lots > of new code written and code integrated from new sources to accomplish > this. The 13.04 Desktop would not have any of this new code, and therefore > will be "old" before it is even released. > > Therefore, I think we should keep LTS releases, but starting now, stop > doing interim releases and start a rolling release. > > More clearly, I think we should: > * Stop making interim releases. > * Keep doing daily quality and keep improving our daily quality. > * Take a monthly snapshot of the development release, which we support > only until the next snapshot > > That means users could choose: > * The LTS release > * The rolling release updated daily or as frequently as desired > * The rolling release updated at least monthly > > = Benefits of Moving to a Rolling Release = > A rolling release instead of interim releases will benefit users, > community members, and developers. > > == For Users == > Users who prefer the LTS releases will be unaffected by this change, at > least directly. For users who prefer more up to date software, the rolling > release will truly provide the latest and greatest software that they are > looking for, but without the 6 month wait for a new release. Developers > won’t be under pressure to rush a feature in before the release deadline, > so users will be receiving more complete software when they do get updates. > > == For Community == > The community will benefit from the simplified model. They will be able to > recommend either the LTS or the rolling release, and the users of each will > be clear. People who need to provide support may find their lives > dramatically simplified, because on any one day, there will essentially be > 2 releases with clearly differentiated user bases instead of their user > base being distributed across a minimum of 3 supported releases. For > example, on any one day, an ISV typically would only have to worry about > the LTS releases and the current rolling release, instead of 11.10, 12.04, > 12.10 and the current development releases, Raring. > > == For Core/MOTU Developers == > For the people who are actually
Let's Discuss Interim Releases (and a Rolling Release)
= tl;dr = Ubuntu has an amazing opportunity in the next 7-8 months to deliver a Phone OS that will be widely adopted by users and industry while also putting into place the foundation for a truly converged OS. To succeed at this we will need both velocity and agility. Therefore, I am starting a discussion about dropping non-LTS releases and move to a rolling release plus LTS releases right now. = Role of the LTS Releases = Many users prefer their OS does not change very often. We have a great system in place for these users. Every 2 years Ubuntu release an LTS and users can ride that LTS for the whole support period. Since the LTS comes out every 2 years, they can set a 2 year cadence of updates if they want to stay "up to date" with LTS releases. I think this 2 year cadence works out very well for these users. So, this proposal maintains those LTS releases as anchors for those users. = Role of the Interim Releases = But what about the 3 releases we do every six months in between (what I call the "interim releases")? Who are they for? Why do we invest so much in supporting multiple interim releases at a time? I think the value of the interim releases has run its course: * Customers (people who pay Canonical and others to support Ubuntu) like OEMs and Enterprises have all adopted an LTS to LTS cadence. * Many community members recommend only LTS releases to new users because of its longevity and stability, but the interim releases cause confusion about what is the “right” version for someone to install. * As Scott James Remnant pointed out some time ago, the six month cadence causes features to be either rushed, or to have to wait for six months to be released (along with other problems). ( http://netsplit.com/2011/09/08/new-ubuntu-release-process/) * Due to Daily Quality efforts, the development release is now usable every day, so enthusiasts and community members don’t have to wait for a stable release to get the latest software and can participate more fully in the development of Ubuntu * Supporting interim releases is a costly distraction from future development, a cost in both time and attention. = Ubuntu NG = In the meantime, with Ubuntu Touch, the Phone, the Tablet, and convergence of these device experiences with the Desktop, we are in the process of inventing what is essentially a next generation Ubuntu. There will be lots of new code written and code integrated from new sources to accomplish this. The 13.04 Desktop would not have any of this new code, and therefore will be "old" before it is even released. Therefore, I think we should keep LTS releases, but starting now, stop doing interim releases and start a rolling release. More clearly, I think we should: * Stop making interim releases. * Keep doing daily quality and keep improving our daily quality. * Take a monthly snapshot of the development release, which we support only until the next snapshot That means users could choose: * The LTS release * The rolling release updated daily or as frequently as desired * The rolling release updated at least monthly = Benefits of Moving to a Rolling Release = A rolling release instead of interim releases will benefit users, community members, and developers. == For Users == Users who prefer the LTS releases will be unaffected by this change, at least directly. For users who prefer more up to date software, the rolling release will truly provide the latest and greatest software that they are looking for, but without the 6 month wait for a new release. Developers won’t be under pressure to rush a feature in before the release deadline, so users will be receiving more complete software when they do get updates. == For Community == The community will benefit from the simplified model. They will be able to recommend either the LTS or the rolling release, and the users of each will be clear. People who need to provide support may find their lives dramatically simplified, because on any one day, there will essentially be 2 releases with clearly differentiated user bases instead of their user base being distributed across a minimum of 3 supported releases. For example, on any one day, an ISV typically would only have to worry about the LTS releases and the current rolling release, instead of 11.10, 12.04, 12.10 and the current development releases, Raring. == For Core/MOTU Developers == For the people who are actually making Ubuntu (the people on this thread I hope) there are some clear wins as well. 1. Only 2 releases to support, the LTS and the rolling releases. That means fewer SRUs to worry about, and only for LTS releases. More time and attention to focus on what we are building instead of what we had built. 2. Features land when they are ready, not earlier or later. 3. No one will get stuck supporting "old" software that is not part of an LTS release. = Why Now? = There are two answers for this. 1. Because of Convergence 2. Because we can == Convergence == The vision before us is f
Re: Proposing a New App Developer Upload Process
David, et al ... Thanks for the hard word and driving to such detail. I think the foundation of most of this work is the section on application sandboxing. If we can make it much less likely that a poorly written or out and out malicious application will bite users, than we will have a lot more freedom to automate the process. This, in turn, will allow us to let application developers reach users and update their applications in a way that makes sense for their apps and their users, without needing a third party (us!) to get in between. Until we have the sandboxing in place, I don't think that there is really much we can do dramatically improve this situation. As such, I think sandboxing should to be a high priority for 13.04. Cheers, Rick PS: For dorky reasons, I prefer the term "application insulation" to "sandboxing" -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: PulseAudio 2.1 now available for testing for quantal.
If we haven't already, perhaps the community testing team could create some test cases and recruit some folks with specific hardware profiles to do some rigorous test case driven testing. That way we can be more confident that the new audio stack was exercised fully and on different hardware, rather than assuming "no news is good news. Cheers, Rick On Fri, Jul 20, 2012 at 6:57 AM, Luke Yelavich wrote: > Hey folks, > PulseAudio 2.1 was recently released, and the audio team would like to get > this into quantal at some point, but before we do, some testing is required > to make sure things don't massively break. We don't believe they will, but > its better to be sure. > > PulseAudio 2.1 packages are available in the Ubuntu Audio dev PPA, > https://launchpad.net/~ubuntu-audio-dev/+archive for quantal. > > If you find any regressions with PulseAudio 2.1, please file a bug against > pulseaudio in launchpad, and clearly state in the bug subject that you are > testing PulseAudio 2.1. > > Thanks in advance. > > Luke > > -- > 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: Releasing Alphas and Betas without "freezing"
On Thu, Jun 21, 2012 at 6:43 PM, Jono Bacon > > The Kubuntu team are welcome to determine whatever milestones they > want - no one is suggesting anything needs to change for the flavors > in their testing cadence. I am purely stating how Nick will be > working: the only output of this work is assured mandatory test case > testing and this testing uncovering any bugs. As I said earlier, this > work is independent of whether we remove milestones or not. I think the terminology here is the source of some confusion. I think when you (Jono) say "milestones" people hear specifically the already defined "alpha and beta" Milestones. I don't think you mean that. I think you are using the term "milestones" differently, to just mean "chosen dates for testing". I think it's fair to say that flavors can choose a higher frequency for a testing cadence than just the alpha and beta dates, Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On Thu, Jun 21, 2012 at 6:02 PM, Michael Casadevall wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/20/2012 11:14 PM, Jono Bacon wrote: >> On Wed, Jun 20, 2012 at 9:24 PM, Scott Kitterman > wrote: >>> On Wednesday, June 20, 2012 09:13:17 PM Jono Bacon wrote: On Wed, Jun 20, 2012 at 8:52 PM, Scott Kitterman > >>> wrote: >> For our current Ubuntu ISOs. Flavors currently are >> coordinating > their >> own testing efforts. They could either latch into the two >> week cadence, or use their own cadence if desired. > > > All flavors as it stands right now are actually coordinated to a > common testing and QA cycle based around milestones, as set forth by > the release manager and the manifest. At each milestone, all images, > regardless of backing are tested. If they fail they're removed from > the manifest, and are excluded from the release. > > I find it somewhat unfortunate that the "community" testing > efforts exclude the community sponsored flavors in the Ubuntu > project. I > would > have hoped that the community team was not just about > Canonical's products. This shouldn't be a particularly big surprise; Canonical supports our flavors with infrastructure, but we primarily focus our engineering and community team staff members on Ubuntu. > > No one is objecting to additional QA efforts dedicated to Canonical > images. That being said, I've yet to see a stated reason on why this > additional QA drive requires changing the milestone process. As Scott > clearly points out what is being proposed will change the > QA/milestone/release process will cause a fair bit of large grief for > all flavors. Nothing is being proposed by Jono other than saying they will strive to increase the testing cadence for Ubuntu, which as you state is not related to alphas and betas. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
I think this was a very productive discussion. We considered a lot of possibilities from a lot of angles. All told, I think there are four points under discussion. I'd like to tease them out so we can move forward. Question 1: shall we stop freezing the archive at milestones? I believe there is not 100% consensus on this point, but enough support to try it for Alpha 2, a la Theirry's suggestion. QA Team/Foundations Team, do we/will we have the tools in place for Alpha 2? Question 2: shall we stop having milestones altogether? This question arose in thread. I don't believe there is consensus for doing this suddenly in 12.10. Question 3: shall we increase the rate of manual testing? This question also arose in the thread. I think there is widespread consensus that we should do this, and it is not actually related to the other questions. Community Team, is it feasible to increase the rate of full manual testing runs to every 2 weeks or similar? Question 4: shall we keep snapshots of the development release so that we can "bisect" more easily and find when bugs were introduced? This question also arose, and also is not tied to the other questions. QA Team, is it feasible to keep a set of snap shots somewhere for this purpose? Cheers, Rici -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On Wed, Jun 20, 2012 at 5:56 AM, Martin Pitt wrote: > Scott Kitterman [2012-06-19 22:16 -0400]: >> +1 > > +1 as well, thanks Michael and Scott. > > Also, saying "we'll drop milestones and introduce a regular schedule > for testing some particular dailies to fix bugs not caught by > automatic tests" means nothing more than a simple renaming -- because > that's exactly what milestones are today. So I also think that proved > nicely what their purpose is and that we cannot do without them. Indeed, the correct cadence of testing is orthogonal to the existence of milestones. If we need more frequent and rigorous manual testing, we should just do it. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On Tue, Jun 19, 2012 at 8:06 PM, Michael Casadevall wrote: > -BEGIN PGP SIGNED MESSAGE- . > > Many critical issues with ARM (and to a lesser extent x86) > have only been found during milestone testing. Without a set of > defined and organized images for testing, more obscure parts of the > installer simply do not get tested; for instance, how many people are > going to test all possible server configurations or test the installer > with no network. But, again, why is the set of "defined organized testing" for milestones? That seems much too infrequent. Dependence on milestones is creating a lack of quality in this area, not improving it. We should not be allowing days to go by without a usable image. And, again, this is completely orthogonal to whether we freeze the archive for milestones, or have milestones at all. In other words, milestones seem a poor means to accomplish your goals here. We should organize a more rigorous and frequent cadence of testing for ARM images. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Reducing Number of Ubuntu Images
On Tue, Jun 19, 2012 at 3:04 AM, Jason Warner wrote: > With that in mind, there is a blueprint here that talks about reducing the > number of images we have and focusing on core images. Specifically, trying > to drive to one 800MB USB image[1]. So the upshot of this is that 12.04 is the last official Ubuntu image that will fit on a CD, right? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On Tue, Jun 19, 2012 at 12:15 AM, Kate Stewart wrote: > > For Alpha1, we did 2 respin sets after the first set was built, > based on what the manual testing was finding and trying to get > a set of ARM desktop images. (Note: We did not have quantal arm > desktop images until the week of alpha 1, and then didn't have them > again with the dailies between 6/10-6/14). Having milestones does force > a focus on the full set of images. Daily images and the automated > testing are still mostly focusing on unit tests for the x86 desktop and > server images in virtualized hardware, and as Martin says, the manual > testing is still finding issues on the real hardware that are causing > respins. I believe there is widespread agreement on this thread that manual testing is good and necessary. I also think there is agreement that a faster cadence of complete manual testing than is accommodated by our current milestones would be desirable. I think it's fair to say that we can move ahead with increasing the frequency of manual testing with or without changes to our milestones. I will look to the Ubuntu Community team to begin with this, as they don't believe they are blocked by any other decisions to be made. I think the question on the table is, shall we drop most milestones altogether, or adopt a system such as Thierry suggests, where we use the most recent "good" daily as the milestone image? There is another question about what is the correct frequency of previous images to archive for purposes of "bisecting". This is also not directly tied to our milestone process. I suspect that a weekly snapshot would be quite useful, but we would have to determine how and where to store those snapshots, and for which images. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On Mon, Jun 18, 2012 at 7:02 AM, Martin Pitt wrote: > Sebastien Bacher [2012-06-15 17:26 +0200]: >> Can we just drop the image rolling part of milestones? We still >> probably want fixed checkpoints in the cycle to review the features, >> etc but they don't especially need to be linked with a special >> image... > > Our automated tests are still wy to incomplete for this step. In > manual testing we have found quite a number of real deal-breaker bugs > which the automatic tests didn't pick up. We also need to test the > current images on a wider range of real iron; which is something our > automated QA could do one day, but doesn't right now. > > So regular manual testing rounds are still required, and the points > when we do them might just as well be called "milestones". But if the focus is testing, we should optimize the schedule around testing. For example, I think Ubuntu would benefit from more frequent "rounds" of such in depth testing than the current alpha/beta milestones provide. (I think every 2 weeks would be a good cadence). Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
(I changed the subject to better represent this branch of the conversation) This discussion suggests that we don't need to release special alpha and beta ISOs, but we do need: 1. A cadence of testing 2. A trial run (or 2) of spinning ISOs 3. Development targets Therefore, I propose we: 1. Stop with the alphas and betas and win back all of the development effort 2. *Increase* the cadence of ISO testing to whatever we want or whatever the community team can manage 3. Spin a trial ISO near what is not beta time (maybe around current kernel freeze?) 4. Spin ISOs for release candidates 5. Maintain the current Alpha and Beta designations as development targets only (i.e. don't spin a special image for them). Cheers, Rick On Sun, Jun 17, 2012 at 11:25 PM, Robert Ancell wrote: > On 16/06/12 02:12, Rick Spencer wrote: >> In short, freezing the archive before an alpha or beta should not >> actually be contributing to either ensuring the installability of >> Ubuntu images or ensuring the quality of these images. This implies, >> therefore, that all the work around freezing, and all the productivity >> lost during a freeze, actually subtracts from the quality of Ubuntu by >> reducing our overall velocity for both features and bug fixes, since >> every day the image is good quality, and Alpha or Beta should be just >> that day's image tagged appropriately. > In particular I find the alpha freeze kills our velocity and I wonder > how more useful than a daily build the alpha release is (given it's so > early in the cycle anyway). I'd support dropping the alpha and pointing > at the dailies. > > -- > 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: Releasing Alphas and Betas without "freezing"
On Fri, Jun 15, 2012 at 4:48 PM, Scott Kitterman wrote: > On Friday, June 15, 2012 04:41:51 PM Rick Spencer wrote: > ... >> The essential point is, Ubuntu should be good every day. There should >> be nothing special about an alpha or beta, it's simply the daily image >> on some chosen day. Making them special doesn't buy us anything, but >> has costs. > ... > Then cancel the whole milestone process, grab a daily and call it done. Kinda what I'm saying, yeah. I think we probably still need milestones for targeting bug fixes and features, but we could change that to be keyed off of months. I think there are also widespread external expectations that there are alphas and betas in a software project so I'm not quite ready to advocate for "no alpha and betas" at all. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
>> Cheers, Rick > > Hi Rick, > > We certainly want to allow people to upload stuff to -proposed during a > milestone week, but I don't agree that we should automatically copy from > -proposed to the release pocket during a milestone week. > > We usually try to release all our images with the same versions of the > packages, considering it takes us hours to rebuild everything, having > seeded packages land during that time, will lead to images having > different version of packages. > > As for what happened with Alpha 1, we simply asked everyone to upload > their packages to -proposed and then cherry picked the packages we > actually needed for the release from -proposed and copied them into the > release pocket before rebuilding the images (we did that 3 times). If you have to go in and cherry pick packages to copy over, would it not make more sense to simply automatically copy everything over? Everything will be properly built before it is copied over anyway, right? > > > As I understand it, the plan going forward is to have the release pocket > be an alias of -proposed on upload, so that everything always lands into > -proposed. > After something lands in -proposed, is properly built and passes > whatever other criteria we'll have, the package will be automatically > copied to the release pocket. > > That last part (copy to the release pocket) would be what we'd block > during a milestone week for any package that's seeded. These would be > copied on a case by case basis by the release team and the images > rebuilt afterwards. This sounds exactly like a freeze. You upload a package and it doesn't land in the distro for a week. That's a serious drag on velocity, and I don't see that it buys us anything but lost productivity and busy work as I described in my initial mail. The essential point is, Ubuntu should be good every day. There should be nothing special about an alpha or beta, it's simply the daily image on some chosen day. Making them special doesn't buy us anything, but has costs. > > That'd essentially allow any non-seeded package to still flow to the > release pocket and be available for everyone. > All the others will be available for people running with -proposed > enabled or will be available when we manually copy them to the release > pocket or right after we release the milestone and we copy everything > left in -proposed to the release pocket. I thought it was specifically an anti-goal for people to run proposed during the development release. It would just expose developers to all the problems that we have without having proposed at all, and furthermore means that some developers are using proposed, while others aren't, splitting attention and sewing confusion. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Releasing Alphas and Betas without "freezing"
Hello all, At UDS I had some "hallway discussions" about why we freeze for Alphas and Betas, and the fact that I think it is time to drop this practice and rather focus on making Ubuntu good quality each day. Sadly, there was no session on this, thus this email to this list for discussion. I think it is time drop our "Freeze" practices for the alphas and betas. Here is my reasoning: 1. We are developing tools that allow us to efficiently use -proposed in a way that will ensure we will not have partially built or incompatible components in the release pocket ... ever. Including days we release Alphas and Betas: These blueprints tools to ensure that Ubuntu is not uninstallable or have other problems due to partially built components and such: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upload-intermediary https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-proposed I have been assured that the tools necessary to automate the work of moving components correctly from -proposed to the release will be ready before Alpha 2. 2. We are investing heavily in the daily quality of Ubuntu. For example ... We run the same automated tests on an alpha as we run on a daily: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/ We tend to archive issues each day: http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html We ran all the manual ISO tests *before* we released Alpha 1, and we have the capability of doing this at will: http://iso.qa.ubuntu.com/qatracker/milestones/221/builds In short, freezing the archive before an alpha or beta should not actually be contributing to either ensuring the installability of Ubuntu images or ensuring the quality of these images. This implies, therefore, that all the work around freezing, and all the productivity lost during a freeze, actually subtracts from the quality of Ubuntu by reducing our overall velocity for both features and bug fixes, since every day the image is good quality, and Alpha or Beta should be just that day's image tagged appropriately. AIUI, A1 was delivered in such a manner, though without the tooling to ensure that moving from -proposed to the release pocket was efficient and automated. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Brainstorming for UDS-Q - Build Prioritization
I think this is a brilliant idea. I think that "keep ISOs buildable" would have a wonderful impact on everyone's velocity and quality. Cheers, Rick On Fri, Apr 13, 2012 at 4:22 PM, Scott Kitterman wrote: > I won't be at UDS, so if this is of interest to someone, I would really > like > it if someone who is would take the ball and run with it. > > Currently build sequence on the buildds is determined (primarily) by a > combination of pocket and component: > > https://help.launchpad.net/Packaging/BuildScores > > In my opinion, one of the major reasons to prioritize builds is to help > keep > ISOs buildable. During non-freeze periods it is not at all rare for > flavors > built out of Universe to go days without a successful image build on some > architectures due to archive skew. > > I think we should change the scoring model in Launchpad (yes, this would > be an > LP change, but I think it should be driven by Ubuntu) to include a > seeded/unseeded element as well. This would give us more images available > for > testing on a regular basis without having to get special respins. > > This could either be done by dropping the current component based score > changes and substituting a seeded/unseeded differential or by adding an > additional score differential for seeded-in-ubuntu packages on top of the > existing model. > > Scott K > > -- > 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: [RFC] Proposal to disable Wubi Installs from 12.04 (but maintain the separate .exe)
Hello all, To complete the discussion, based on the below comments and others, I logged the following bug: https://bugs.launchpad.net/wubi/+bug/975251 "please hide the "install ubuntu" option from wubi.exe on the CD" It seems to be Fixed Relese already. Cheers, Rick On Tue, Mar 27, 2012 at 4:43 PM, Evan Dandrea wrote: > On Tue, Mar 20, 2012 at 5:07 PM, Kees Cook wrote: > > On Tue, Mar 20, 2012 at 09:37:06AM -0700, Steve Langasek wrote: > >> 3. We disable the ability to do a wubi installation from the Ubuntu > 12.04 > >> ISOs. (wubi will remain on the images for the purpose of providing > Windows > >> users some feedback and functionality if they put a Ubuntu CD into a > >> running Windows computer, but won't offer to install). > >> > >> At this time, we don't expect to be able to reclaim any space on the ISO > >> with this change. In the future we may consider splitting the autorun > menu > >> out of wubi.exe to save some space (this is how it was structured > >> originally), but it's very late in the cycle to attempt such a > refactoring > >> for 12.04. It's safer to simply disable the "install" option when run > from > >> the CD. > > > > Oh, whoops. I re-read Rick's email a few times and continued to miss > that. > > > > What kind of feedback is shown with this change? Is it actually useful > > (i.e. not just "install" greyed out)? > > Apologies for the late reply. > > It would look something like this (not sure what happened to the > anti-aliasing there): > http://people.canonical.com/~evand/tmp/wubi_without_wubi.png > > The "demo and full installation" option puts the Ubuntu installation > medium into the Windows bootloader, so the user doesn't have to faff > about with their BIOS settings. The "learn more" option takes you to > http://www.ubuntu.com. > > -- > 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
[RFC] Proposal to disable Wubi Installs from 12.04 (but maintain the separate .exe)
Hello all, This email regards wubi, a tool used to set up Ubuntu in a dual boot configuration in a manner that does not require disk partitioning. Wubi is a windows program. It is currently delivered as a standalone executable downloadable from the web, as well as part of official Ubuntu images. You can read about wubi in the excellent user guide: https://wiki.ubuntu.com/WubiGuide I am proposing a small but notable change to how we deliver wubi for 12.04. I am proposing that: 1. We continue to test and bug fix wubi.exe as the separate Windows program 2. We cotinue to offer wubi.exe for download as the separate Windows program. 3. We disable the ability to do a wubi installation from the Ubuntu 12.04 ISOs. (wubi will remain on the images for the purpose of providing Windows users some feedback and functionality if they put a Ubuntu CD into a running Windows computer, but won't offer to install). Separating the wubi.exe experience from the ISOs will give us the following important benefits: 1. We will be able to do maintenance and enhancements to wubi outside of the Ubuntu development cycle. 2. Significant reduciton of QA work for an already over-streched QA team. 3. Better overall 12.04 quality, and less stress at release time. 4. We won't get stuck with a poor (or worse) user experience on the CD since is a good chance that wubi will not work properly with Windows 8. I am proposing these changes to the plan because: 1. The key use case for wubi is being able to download and run the installer on Windows, not installing from the ISO. 2. Wubi is difficult to test, so has been difficult to assure that it will meet the quality standards we have set for 12.04. 3. There are no developers treating wubi as their top priorities. This combined with the QA difficulties has historically caused late breaking changes that add stress at release time and frequentily invalidate already executed ISO testing. 4. Most significantly, Windows is changing it's boot system with Windows 8, and it's not clear how wubi will work with Windows 8, if at all. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Testing in Ubuntu BoF at UDS: 7pm on Wednesday
Brad, I'm not opposed to having it in the evening or during the day. However, I think the idea of having it in the evening was that it would not conflict with other sessions, so then more people could attend. Also, with some pizza and beer it could double as a social event. If folks think having it during the day is a better idea, and in fact want other BoFs, I am sure we can accommodate that. Cheers, Rick On 10/04/2011 09:23 PM, Brad Figg wrote: On 10/04/2011 09:59 AM, Evan Dandrea wrote: Following all the excitement around better integrating automated testing into our development process, we're holding the first-ever Testing in Ubuntu Birds of a Feather session at UDS-P. It will take place at 7pm on Wednesday night. Pizza and drinks will be provided. We're looking for volunteers to give 5 minute lightning talks on cool things they've come across, created, or big ideas they have, as they relate to automated testing. It doesn't have to be Ubuntu-specific, but please pick a topic that would be helpful to those developing Ubuntu infrastructure. Please sign up here, if you're interested: https://wiki.ubuntu.com/UDS-P/TestingInUbuntu Even, I think this is a great idea. However, I'd like to see it done during the day. I think testing is important enough it shouldn't be relegated to an after hours event. Personally, I'd like to see more BoFs at UDS. Brad -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Error database requirements
On Fri, 2011-08-12 at 12:41 +1200, Robert Collins wrote: > On Fri, Aug 12, 2011 at 6:52 AM, Bryce Harrington wrote: > > 2. I notice the Windows crash reporter includes buttons to check for > >existing solutions. Is that something we'd like to consider as a > >requirement for this? > - allowing users to follow up on their report [if desired - note that > Microsoft's tool *used* to do this, now they don't] I think that the purpose of the this project needs to stay focused on help us figure out which are the widespread crashers that are impacting users in a stable release and should therefore be fixed via SRUs. Therefore, I think this effort needs to stay targeted at *collecting* data from *all* will users. I don't think this should be an interactive feature designed only for technical users (who care to follow up on bug reports or try to puzzle out how to solve their problems). We should, therefore, minimize or even eliminate user interactivity, and collect the minimum data necessary to correlate crash reports. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Crash database requirements
On 08/11/2011 12:02 PM, Matthew Paul Thomas wrote: To this list I'd add: * It should be brainlessly easy for users to submit this data. Either a single "Yes, submit this crash" confirmation, or a check box to automatically submit these crashes. One of the features that the X team really desire out of this sort of database is "how frequent is this kind of problem", which requires the widest possible sample space. With my proposed design it's two clicks to submit, then another click to dismiss the error message. Probably I should simplify it further. Would it not be possible for the user to opt in, and then have the reports submitted silently in the background on behalf of the user without bothering them at all? If I had a butler, I would be annoyed if he asked me to ok crash reports before he sent them in for me. I'd want to tell the butler "just send the crash reports without bothering me about them". Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Crash database requirements (was: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions))
On Mon, 2011-08-08 at 19:44 +1200, Robert Collins wrote: > On Mon, Aug 8, 2011 at 6:25 PM, Christopher James Halse Rogers > wrote: > The LP team doesn't *currently* have working on this in our short term > plans; if the stakeholders wanted to negotiate queue jumping, we could > put a squad on it at the end of the next(ish) project, or some folk > may do something in scratch time (like my experiment with cassandra > has been). > I'm wondering why the launchpad team would work on this. It seems that the desire is to collect the crash data outside of lp bug reports. Am I missing something? Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions)
On Sun, 2011-08-07 at 22:46 -0700, Bryce Harrington wrote: > On Mon, Aug 08, 2011 at 07:17:52AM +0200, Rick Spencer wrote: > > On Sat, 2011-08-06 at 15:46 -0700, Bryce Harrington wrote: > > > > > > > > I think we are doing it wrong: we should collect > > > > crashes on all supported releases. > > > > > > I agree. As designed, apport files a new bug report for each crash, > > > which can quickly lead to excessive numbers of dupe bug reports (there > > > are ways of making apport auto-dupe, but this takes effort to set up and > > > isn't always 100% reliable). This can quickly become unmanageable > > > especially for packages that lack someone to keep an eye on the bug > > > reports. > > > > > > In any case, these types of reports post-release are most useful in > > > aggregate rather than as individual bug reports. If they were filed in > > > some ultra simple crash database (with no signup required of the user) > > > we could get most of the value without incurring a lot of extra bug > > > labor. > > Has this very thing not been proposed? We should discuss doing this for > > 12.04. > > It's been propsed and discussed previously, like ScottK mentioned. The > issue has been finding someone with time to work on it. I think we should be able to fix this for 12.04. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions)
On Sat, 2011-08-06 at 15:46 -0700, Bryce Harrington wrote: > > > > I think we are doing it wrong: we should collect > > crashes on all supported releases. > > I agree. As designed, apport files a new bug report for each crash, > which can quickly lead to excessive numbers of dupe bug reports (there > are ways of making apport auto-dupe, but this takes effort to set up and > isn't always 100% reliable). This can quickly become unmanageable > especially for packages that lack someone to keep an eye on the bug > reports. > > In any case, these types of reports post-release are most useful in > aggregate rather than as individual bug reports. If they were filed in > some ultra simple crash database (with no signup required of the user) > we could get most of the value without incurring a lot of extra bug > labor. Has this very thing not been proposed? We should discuss doing this for 12.04. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Default Desktop Experience for 11.04 - User testing results
On Sun, 2011-04-17 at 09:17 +0100, Paul Sladen wrote: > On Fri, 15 Apr 2011, Rick Spencer wrote: > > > > For brand new users? Some of the tasks aren't relevant. > > > Which ones? > > Changing the background image and setting in general. > > On the contrary. Changing the wallpaper and screensaver are comforting > personalisation steps that new users seem to undertake on their own. That was my point. You don't personalize something until you *own* it. Until you've used it enough that you know how you want to own it. It's not something you do while you are carrying out other tasks. In any case, it's a moot point, since changing the desktop background was something that the study found users could do easily, they were blocked by the usability engineer telling them not to do it in the obvious manner. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Default Desktop Experience for 11.04 - User testing results
On Fri, 2011-04-15 at 23:29 +0100, Matthew Paul Thomas wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Rick Spencer wrote on 15/04/11 15:08: > > > > First, thanks Usability Team! I know how much work goes into planning > > and running a study like this, and how much agony is involved in > > interpreting and writing up the results. It's clear that there are some > > areas for improvement in 11.10, and these results will be instrumental > > in helping to guide those investments. > > Charline did all the planning and test moderation. I was just the > stenographer afterwards. > > Later on, Charline will publish a full report on the test. I just wanted > to post a quick summary in time to be helpful for the default experience > discussion. > > > On Thu, 2011-04-14 at 22:48 -0700, Bryce Harrington wrote: > >> > >> On Fri, Apr 15, 2011 at 03:00:31AM +0100, Matthew Paul Thomas wrote: > >>> > >>> * 8/10 people could find a window's menus, but 7/8 of them learned to > >>> * Only 4/11 worked out how to change the background picture. > >>> * 6/10 could easily find and launch a game that wasn't in the > >>> * Only 1/9 (P4) easily added that game to the launcher. > >>> * 9/11 people could easily close a window. > >>> * 8/9 easily copied text from one document into another. > >>> * Only 5/10 could easily delete a document > >> > >> These seven items in particular seem like really basic tasks that > >> ought to be testing at >90%, so these stats seem a lot lower than I'd > >> expect. > > > Well, think back to the last time you got a new device. For example, if > > you have an Android phone. You are probably pretty facile with the > > interface now, but if someone handed it to you and said "do this task > > with it" you may have struggled to some basic things, like launching > > apps. A lot of the fun for users in getting a new devices is learning > > how to use it. > > I didn't have anything close to that kind of trouble when trying out an > Android phone. (Though like anyone on a developer mailing list, I'm not > a representative sample.) Oh? I recall learning many things on my phone. How to launch apps. How to use the task manager to switch between running apps. How to enter text in general and swype in particular. How to pull down the notification area and how to push it up again, etc... If you were watching over my shoulder you may have said "Fail Fail Fail" many times. Perhaps you would have been correct, the usabliity could be better. However, it's easy to forget the first few times you satisficed through something compared to the hundreds of times you've done something after you mastered it. > > >... > > For brand new users? Some of the tasks aren't relevant. > > Which ones? I believe the following are tasks indicative of repeated and experienced usage, not first time usage: * Changing the background image and setting in general. * Adding a game to the launcher. * Rearranging items in the launcher. And these were some that users had the most trouble with. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Default Desktop Experience for 11.04 - User testing results
First, thanks Usability Team! I know how much work goes into planning and running a study like this, and how much agony is involved in interpreting and writing up the results. It's clear that there are some areas for improvement in 11.10, and these results will be instrumental in helping to guide those investments. On Thu, 2011-04-14 at 22:48 -0700, Bryce Harrington wrote: > On Fri, Apr 15, 2011 at 03:00:31AM +0100, Matthew Paul Thomas wrote: > > * 8/10 people could find a window's menus, but 7/8 of them learned to > > * Only 4/11 worked out how to change the background picture. > > * 6/10 could easily find and launch a game that wasn't in the > > * Only 1/9 (P4) easily added that game to the launcher. > > * 9/11 people could easily close a window. > > * 8/9 easily copied text from one document into another. > > * Only 5/10 could easily delete a document > > These seven items in particular seem like really basic tasks that ought > to be testing at >90%, so these stats seem a lot lower than I'd expect. Well, think back to the last time you got a new device. For example, if you have an Android phone. You are probably pretty facile with the interface now, but if someone handed it to you and said "do this task with it" you may have struggled to some basic things, like launching apps. A lot of the fun for users in getting a new devices is learning how to use it. Given my experience, these numbers look they could be improved, but I don't find them particularly concerning. For example, you can easily use Unity quite productively before you learn that you can add items to the launcher, or change the background picture, though I suspect many Windows users would right-click and the desktop to set the background picture and would do fine. The only area here that is at all concerning to me regards launching applications. I'd like to see some focus on the application lens in 11.10 (see what I did I did there? :) ) > > I'm curious whether these stats are higher/lower/same-as with Classic > Desktop. IOW this needs a control group so we can tell if the new > design brings improvement or regression. For brand new users? Some of the tasks aren't relevant. For others, like finding installed applications, I presume this was dead easy in Classic GNOME, but it's hard to say for a certain. > > Also, these tests measure usability, but not their overall impression. > Did they like it? Find it frustrating/confusing? This is actually a very important question. For me, when I go back to Classic, it feels very old and mundane. Many theories hold that the aesthetics trump usability, or at least strongly influence the perception of the usability of a system. In other words, given 2 identically design systems that only differ in terms of theming, for example, users will rate the system with the more pleasing design to be more "usable" and are more likely to start using it. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Default Desktop Experience for 11.04
Hello all, Back at UDS for 11.04 in Orlando, Mark set the goal of using Unity by default on the Ubutu desktop. Given the current course of development, it appears that we are going to achieve this goal, and Unity will stay the default for 11.04. I'm following up on this list at the suggestion of the Tech Board to give folks a chance to respond or escelate any concerns. Note that there are some arguments for changing the default from Unity to "classic' GNOME: 1. There are key feature regressions, for example, there is no systray support for many important applications. 2. There are usability problems, for example, settings are hard to find, the launcher icons behave differently when you click on the trash can versus the home folder launcher, it's hard to find a categorized view of applications, searches do not always turn up expected results. 3. We are coming in too hot, there are too many crashers on some hardware and the final product will be buggy. I won't rebut these points myself, as I am rather striving to represent the viewpoints not argue against them. Representing the desktop team, Jason Warner believes that Unity will deliver the superior experience for most users in 11.04. I agree with this position and support staying the course. Cheers, Rick PS - You can reference the recent and current bug fixing efforts of the Unity team here: https://launchpad.net/unity/+milestone/3.8.4 https://launchpad.net/unity/+milestone/3.8.6 https://bugs.launchpad.net/ubuntu/+source/unity -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Integrating new console colors in D-I (was Re: Call for testing: Aubergine-love for Server folks!)
I like this feature, but I have a few questions about it. 1. I presume this is the bug: https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/730672 But there doesn't seem to be an FFE for it, but perhaps I am confused about when and how the feature landed. The bug mentions UI freeze, but not feature freeze, though it seems the bug itself was logged after feature freeze. 2. Considering there is still churn on how to implement the feature, it gives me the feeling of something that this is just a bit too late for Natty. We should be 100% focused on converging in this release. There are plenty more bugs to work on, and this seems to be causing work for people who could be fixing those bugs. Please let me know if I missed the conversation elsewhere, or if the feature was properly handled with a FFE, and I just missed that part. Cheers, Rick On Sat, 2011-03-26 at 15:21 +, Colin Watson wrote: > On Sat, Mar 19, 2011 at 05:54:59PM -0400, Stéphane Graber wrote: > > What about making that change preseedable ? > > > > This way ubuntu-alternate and ubuntu-server can ship with the new > > palette set in the .seed files included on the CD and everyone else will > > get the old VGA colors. > > It would have to go on the kernel command line, not in the CD preseed > file. The latter is read too late for this. > > It would probably be better to add new values for the existing > FRONTEND_BACKGROUND environment variable (which can also go on the > kernel command line) rather than inventing a new preseeded template > which would basically just be a synonym for it. > > -- > Colin Watson [cjwat...@ubuntu.com] > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Shall we hide the GUI for Hibernate in Natty?
Hello all, This email is to get some feedback and discussion about an idea under consideration for Ubuntu in Natty. Natty is currently NOT showing the Hibernate option in the list of shutdown choices. This is currently an experiment, but I thought it might be worth discussing the pros and cons on these lists as well. The reasoning for hiding Hibernate includes: 1. It doesn't work well for many users on many machines. 2. It's very slow. 3. It's not as useful because users can just suspend. 4. The difference between hibernate and suspend is confusing. 5. There is a lot of work involved with verifying that Hibernates works and fixing bugs to ensure that it works. This work is not always completed, and the work that does get done can be channeled to other useful areas. (In other words, fewer bugs through fewer features to support). However, Hibernate works well for some users, so this will be a painful regression[1]. Please note that currently: 1. No decision has been taken, it's just an experiment and is very open to discussion at this point. 2. The feature is hidden in the UI, but can be turned back on by tweaking, /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla 3. The desktop team decided that session saving (in Gnome) is unsalvagable, so removing hibernate would mean that there is no way to save state across powerdowns/powerups.[2] So, thoughts, discussion, feedback, options, suggestions, rants, raves, etc... ? Cheers, Rick [1] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/710796 [2] https://lists.ubuntu.com/archives/ubuntu-desktop/2011-January/002734.html -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Compatibility between Ubuntu and GNOME developer strategies
On Thu, 2010-12-16 at 17:22 +, Phil Bull wrote: > Hi Rick, > > On Thu, 2010-12-16 at 07:55 -0800, Rick Spencer wrote: > [...] > > Quickly uses abstract commands like "package", "release", etc... > > specifically so that those commands can be implemented per distribution. > > So the user could surf across distros, and use the same command set, but > > get distro specific behaviors. For example, on some distros "package" > > would produce a .deb, and on some distros an .rpm. I would be delighted > > to see Quickly templates for other distros. > > > > Quickly has an API, so it should be easy to integrate it with Anjuta or > > any other IDE. That combined with distro specific Quickly templates > > could provide a consistent developer experience across distros. > > This sounds great. Do you know if anyone has been working on Quickly > support for other distros? If not, how much work do you think it would > take to get it working on, say, Fedora? I think it's packaged for Fedora, but I don't think the distro specific parts have been tweaked. > > Also, does Quickly make strong assumptions about the development > environment (i.e. PyGTK), or would it be easy to extend to other > languages (JavaScript, for instance)? Quickly makes both strong assumptions, and also no assumptions. A template is a combination of boiler plate code and commands to run on that code. So we have a template called ubuntu-application. It uses PyGtk and a bunch of other technologies. And then you start a project by running: $quickly create ubuntu-application my-project-name The idea is that you can easily replace the "ubuntu-application" part with whatever you want. For example, you could fork the ubuntu-application template to make fedora-application. You could change the preferences to use something other than desktopcouch for persistence, and change the package command to create an rpm instead of deb. You could also create all new template that uses javascript for the boiler plate code. Quickly actually has 3 "official" templates right now (application, cli, and pygame). All of these happen to use Python, but there is no inherent limitation there. > > [...] > > The Ubuntu community is working on a project called the Ubuntu > > Developers Manual. This will, of course, be licenses so that it can be a > > shared resource across distros and also be enhanced to have distro > > specific tweaks. > > I hadn't heard about this - who's working on it? It seems to me that > there could be a great deal of overlap with the stuff that's happening > in GNOME at the moment. It might be more fruitful to work together on > just the one set of documentation, but that does rather depend on what > the aim and content of the Ubuntu developers manual is. Indeed, there does seem to be a lot of overlap, and a flow of effort between the projects seems quite sensible and desirable. The intent of the manual is that it is a short concise guide that provides one path to success with developing on Ubuntu. It may not shock you to hear that Quickly, PyGtk, and Launchpad all factor into it heavily ;) We coordinate through the launchpad team and mailing list: https://edge.launchpad.net/~ubuntu-developer-manual There's some content in the project tree too. It's an open team, so I hope people feel more than welcome to join and discuss. We also tend to hang out in #quickly on freenode when we are discussing. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Compatibility between Ubuntu and GNOME developer strategies
On Fri, 2010-12-10 at 17:18 +, Phil Bull wrote: > Hi guys, > > I attended the "GNOME Developer Documentation and Tools" hackfest in > Berlin last week. The aim of the hackfest was to work on improving > resources for developers who use (or want to use) the GNOME platform. A > number of interesting issues were discussed and we made good progress > addressing some them (see [1][2][3] for summaries). I'd like to make > sure that Ubuntu derives full benefit from this work, and to encourage > people to come and work upstream on some of it. > > DEVELOPER STORY > > What is Ubuntu's "story" for new developers? That is, how are new > developers, of different "types", introduced to the platform? Is it > based on Quickly? I feel that it would be advantageous to match the > Ubuntu and GNOME stories to as great an extent as possible. That way, > "developers for the GNOME platform" are also "developers for the Ubuntu > platform" and vice versa. Quickly is *a* story for new developers, but the intent is certainly not to limit choice. Quickly apps are gnome apps in that they use pygtk, and all gnome tools for UI. However, the layout of an app, and some of the recommended platform technology choices may vary by distro. > > We developed the GNOME story a little at the hackfest. It's based on > five key GNOME languages (C, C++, JS, Python, Vala), and we intend to > emphasise different languages for different types of developer. The hook > into the platform is a set of exciting, focused tutorials (see below). > We'll also provide a "blessed" (but not exclusive) development > environment, which will probably centre around the Anjuta IDE for coding > and (possibly) the OpenSuSE build service for deployment. It shouldn't > be difficult to provide this environment in Ubuntu. This sounds like a great thing. Recommended paths to success make developer adoption much easier. > > DEPLOYMENT > > Deployment is something that GNOME hasn't really tackled before, but > it's an important part of the story. At the moment, I think it's fair to > say that deployment on desktop Linux is an issue for new developers. > Packaging can be difficult and confusing, and distribution channels > aren't always easy to tap into. Ubuntu has been trying to address this > with initiatives like Quickly and the Software Centre app store. My > question here is, how can we get this sort of thing working upstream so > everyone benefits? (A Quickly plugin for Anjuta was discussed, for > example.) Quickly uses abstract commands like "package", "release", etc... specifically so that those commands can be implemented per distribution. So the user could surf across distros, and use the same command set, but get distro specific behaviors. For example, on some distros "package" would produce a .deb, and on some distros an .rpm. I would be delighted to see Quickly templates for other distros. Quickly has an API, so it should be easy to integrate it with Anjuta or any other IDE. That combined with distro specific Quickly templates could provide a consistent developer experience across distros. > > DOCUMENTATION > > There have been some nice improvements to library.gnome.org and we're > also planning to relaunch the developer.gnome.org portal. This will > feature a new, up-to-date platform overview, good conceptual overviews > of key frameworks/libraries like GStreamer, and a number of quick > tutorials designed to get new developers to "dive in" to GTK/GNOME > development. There's lots more work to be done on these, but the first > batch is looking good. Ideas/development would be especially welcome in > this area - we really need contributors. The Ubuntu community is working on a project called the Ubuntu Developers Manual. This will, of course, be licenses so that it can be a shared resource across distros and also be enhanced to have distro specific tweaks. > > This initiative is still in its infancy but I think that with a bit of > work we can make GNOME (and Ubuntu) an extremely compelling development > platform. I should also emphasise that upstream are very receptive to > input and are extremely keen to cooperate. I think there is a lot of opportunity for collaboration here, as well. I'm looking forward to it. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Unity desktop and maverick backport
In my opinion, for what it is worth, this sounds like an unfortunate, but necessary trade off. I think we will lose a fairly large degree of testing and feedback, by forcing interested contributors to move Natty so early. However, I think it's rational to trade that for an increased focus on the ultimate quality of the new compiz-based unity in Natty and beyond. I think we'll get the most useful feedback from people *using* Unity. So, this means that we'll need to focus on supporting early Natty adopters, for instance paying more attention to quickly resolving adoption blocking bugs. My $.02 Cheers, Rick On Thu, 2010-11-18 at 19:25 +0100, Didier Roche wrote: > Hi everybody, > > As some of you may know, there have been some discussions about > backporting > "unity compiz" to maverick as we had backported unity to lucid with a > dedicated ppa and its own session. > > However, after some porting discussions and following the natty work I > think > we should perhaps consider not doing that because it's going to take > quite > some work for a moderated benefit and we would better spend those > efforts in > making natty rocking. > > Some bits what came from discussions between ubuntu desktop and dx > teams: > > * Why do we want to backport? - usually it's to make easier for users > to test the new version and give some feedback on it. The first round of > feedback will be about things not starting, or not working at all or > crashing, we will get that feedback from the natty users. Later on we > will want extra eyes on the user experience but by the time we are there > it will be really hard to backport the new stack due to new depends > (details on that later). > * New unity means new compiz which means users will have no working > desktop left, that's not something we should get our users in. Indeed, > the new > compiz is not made to be installed with the old one, the upgrade will > replace compiz > 0.8 but has lot of issues still: the configuration is not migrated, the > keybindings are not working, the workspace layout and switcher are not > working, the session registration is not working, the desktop capplet > needs to be updated, the GNOME keybindings capplet is not working. Some > of those > issues are fixed in natty, but we can't backporting every single GNOME > applications > to make them work in a maverick ppa. > - the new unity packaging is not made to have old and new unity > installed at the > same time so the old unity will not be installed anymore. > - the new unity is not usable as a desktop yet, which means the user > will not > have the old unity, compiz under GNOME will be broken is several ways > which let the GNOME session hard to use, the new unity is not ready for > production ... users who will want to give unity a try will just land in > a situation when they have no environment left they can use for work... > it would be less breakage to suggest them to update to natty where we > fix those integration issues. > * The new unity stack will be hard to backport - the next indicators > uploads will build-depends on gtk3 (even if we don't use it we need to > have libraries in natty to build gtk2 and gtk3 version to allow people > to start porting work), we use new glib api, etc. Backporting the stack > unity will need is going to turn into lot of work and a non trivial > task. > > We think users will have a better experience by trying unity on natty > and that we will gather more useful and coherent data, since it's likely > to be more stable than getting a working - and a less tested by our team > - backport. > > > didrocks on behalf of the ubuntu desktop and dx teams > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: continuing conversation from UDS-N - Application Review Board
On Tue, 2010-11-16 at 15:42 -0500, Scott Kitterman wrote: > On Tuesday, November 16, 2010 03:21:46 pm Allison Randal wrote: > > On 11/16/2010 12:08 PM, Scott Kitterman wrote: > > > IIRC, FHS expects /opt//. Perhaps Canonical should > > > register "canonical" if they haven't already and then allocate > > > /opt/canonical/quickly or /opt/canonical/arb namespace to this. Given > > > the way FHS anticipated /opt to be used, I think Canonical (although > > > certainly not ideal) may be the best choice. > > > > /opt/canonical has a similar problem to /opt/ubuntu, in implying > > "officialness" or support from someone (in this case Canonical as a > > company, rather than Ubuntu as a community/project/distro). > > > > But, there seems to be a fundamental tension here between "official > > enough to register with LANANA" and "not too official", so perhaps an > > added level in the path is the best solution, like /opt/ubuntu/extras. > > It is specified in the FHS "The structure of the directories below > > /opt/ is left up to the packager of the software..." with > > /opt// as a suggestion, not a requirement. > > > > Allison > > I can see that. I'd strongly prefer it not be something that is exactly > Ubuntu. Even something like ubuntu-arb or ubuntu-appdevel would be much > better (apps-on-ubuntu?). I don't want to go on record contradicting the Tech Board here, but "extras" seems to me to fit the bill. I don't think users will be exposed to it much, but "extras" seems to imply the kind of "add on" behavior that we are going for. Would it be possible to reconsider "/opt/extras/"? If not, maybe "/opt/addons-ubuntu" to pick up on Scott's idea? Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: continuing conversation from UDS-N - Application Review Board
On Tue, 2010-11-16 at 11:21 -0800, Allison Randal wrote: > - They suggested /opt/ubuntu/ instead of /opt/extras/ > as the private install location, with the note that (respecting the FHS) > we need to register the provider name with LANANA, and "ubuntu" is more > sensible in that general context than "extras". Does "/opt/ubuntu/" perhaps suggest a bit of "officialness" or support from the Ubuntu community, whereas these apps are specifically *not* suppose to have such a connotation? Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: continuing conversation from UDS-N - Application Review Board
On Mon, 2010-11-15 at 17:36 -0500, Barry Warsaw wrote: > On Nov 15, 2010, at 05:27 PM, Scott Kitterman wrote: > > >Unless there is some commitment to API stability, this is actively harmful. > >If you are writing functions to be consumed generally, and not just within > >your program/module/whatever, then you have to take on some additional > >responsiblities. If you don't, then whoever tries to take advantage of your > >code is in for a world of hurt. > > Sure, but this is the "consenting adults" argument. The thing is, the > packages are going to be available in either case, so you're just putting an > inconvenient sys.path hack in front of anyone who really wants to do it. I write apps and libraries as very distinct activities. As an app developer, my supporting libraries tend to be extremely specific to my app in design and functionality, with no thought to external consumers of those libraries. I also do not test any scenarios outside the scope of my app. If I want to write a library for someone else to use, I design for that purpose. So, as a user (as in a user of the app review board) I would just as soon not to have the additional concern of making my supporting libraries also have to be usable by other developers. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
