Re: Congrats on karmic, looking forward lucid
On Wed, Nov 04, 2009 at 03:26:38PM +0100, Martin Pitt wrote: > Sebastien Bacher [2009-11-02 14:45 +0100]: > > Karmic has seen lot of technologies changes (new gdm codebase, > > pulseaudio required by GNOME, empathy by default, devicekit-disks and > > devicekit-power used in GNOME, etc) so it was expected it would have > > some rough edges. > > Indeed, with so many things that changed it's a miracle that it works > in the first place. In retrospect I think we should have announced it > differently, as a "tech preview" release, and not recommend everyone > to upgrade.. It seems this was a smooth release for some, and a hairy release for others. Of about 8 systems I upgraded, I had one (my laptop) which succumbed to rather severe issues and had to be wiped and reinstalled from scratch, but the other systems upgraded cleanly. That said, we are definitely seeing a surge of bug reports against X.org in recent weeks: http://www2.bryceharrington.org:8080/X/Graphs/totals.svg (It literally went off the chart last week. I need to expand the chart...) There were some X breakages caused by the gdm rewrite, and some issues relating to dkms and upstart. However, this breakage was not so much introducing new bugs, but rather making existing bugs worse. I wish we'd had more time for testing so we could have smoothed this out better for people, but I think we've got SRUs in for all the worst aspects of the issues. Anyway, I *think* this increased rate of bug reports is not due to a specific breakage or any reduction in quality in X.org but rather just due to increased numbers of users or at least increased numbers of users sending bug reports. That said, the increased quantity of reports poses a workload issue that troubles me. More on this below. One suggestion that I think might be good would be for releases like Karmic where we feel it is a bit more ambitious technologically, to make update-manager hold off on recommending users upgrade for a few weeks. This would give time for SRUs to make their way through the system for critical issues people run into. In fact, this might even be a good idea for the LTS. Anyway, just wanted to toss out this as an idea. > > - let's not spend too much time on backporting changes to karmic, using > > the next 2 weeks to look at the user feedback, do stable updates to fix > > the most annoying issues until UDS and then move our focus to Lucid > > Full ack. Fwiw, I pretty much ended up spending 100% of my time between release and UDS on SRU bugs (mainly for -nvidia), and still there are a number that could be put in. But given the limited manpower at hand I'm turning attention now to Lucid, since there is much needing to be done there. > > - try to be conservative in the changes which will land in lucid, GNOME > > upstream will likely rework some component in the GNOME3 optic and other > > teams or upstream will probably keep working on changes to improve the > > user experience, while the work they do is great it would probably be > > good to wait until lucid+1 to bring those in the default installation. > > I expect we will have some of those discussions at UDS too > > I just created the initial list of blueprints for lucid which were > requested: > > https://blueprints.launchpad.net/ubuntu/lucid/+specs?searchtext=desktop > > There are some new features there, but a lot of them is > "review"/"cleanup" type of work as well. We might have to drop some > goals, though (the low/medium ones) in favor of working on bug fixes. I would love to be conservative with X this time through. Unfortunately, we've gotten a number of requests for tasks which are going to require pretty major changes to X infrastructure. HAL is to be dropped (which may regress wacom and/or other input devices. We are switching to KMS for radeon (which will likely incur regressions for ATI owners). We will be rearchitecting the way -nvidia and -fglrx are installed; this will solve many long standing issues, but introduces risk. We are moving from -nv to -nouveau+KMS (which will fix some longstanding issues but may introduce new ones for Nvidia owners). The boot performance team has requested several patches which improve boot performance but may expose regressions in less well tested areas. Anyway, all worthwhile changes, although to call it conservative might be a pretty big stretch. ;-) More importantly, the manpower this work will need takes away from stabilization work needed generally in order to get that X.org bug curve leveled out. IOW, "Help!" > That sounds like a very good idea. In the ancient past we had a > "laptop testing team", perhaps we should try to build a "desktop > testing team", where each of the members "adopts" their favourite bit > of the desktop (be that music player handling, photo import, scanning, > beamer support, or whatnot)? I think this could be a good idea, but it depends on how such a team is directed. The way such testing has been traditionally don
Re: Congrats on karmic, looking forward lucid
ma., 02.11.2009 kl. 14.45 +0100, skrev Sebastien Bacher: > Hey everybody, [snip] Hey Seb :) > - try to be conservative in the changes which will land in lucid, GNOME > upstream will likely rework some component in the GNOME3 optic and other > teams or upstream will probably keep working on changes to improve the > user experience, while the work they do is great it would probably be > good to wait until lucid+1 to bring those in the default installation. > I expect we will have some of those discussions at UDS too [snip] It is difficult to overestimate the importance of this. The LTS releases should be the main releases for new users and companies. That means they should not only be stable from day one, but should have high quality documentation, books, and support both commercial and free. One way to accomplish this, I think, is to consider the last release before the LTS a QA release. Between Karmic and Lucid, there should be as little change as possible. Documentation written for Karmic should require only minor changes in order to be applicable to Lucid. One of the key strengths Microsoft has (especially for Win XP), is that everyone knows someone who knows all the secrets and workarounds since they've used it for some time themselves. (I can still do blind support of XP over the phone even though I haven't used it in a year -- I cannot do that with Hardy). If we consider Karmic a QA release to Lucid, we'll have a lot of users who can help their neighbours once Lucid is released. It will also give less technical users more confidence when recommending Ubuntu. We really need that in order to reach the crucial tipping point. I really wish the development of Ubuntu could become something like this: LTS+1 (first release after LTS): time for changing lanes. Radical changes can be done, if it makes sense. I hope we'll refrain from changing stuff for the sole purpose of elevating the fancyfactor. We really push the limits in this release and everyone knows that chances are high that regressions are introduced. This is where we pave the way to the future, and new users aren't made to expect this to be flawless. It should still be useful to normal users of Ubuntu, of course. LTS+2: Push further in the direction set in the previous release, learning from the experiences of the previous cycle, and work on stabilizing the system. Sometimes, good ideas just don't work in practice. This is a good place to revert if we find examples of those. LTS+3: The way forward is now clear. Refine the changes from the two previous cycles, preparing for the LTS. We now know mostly what the LTS will be like, so greater resources can be put into writing long-term documentation, books, screencasts, etc. Since we have six months to do this work, we can try to make this available in more languages in a more consistent way. People have been expecting this six-month QA period, and have planned for it so they have time to work on marketing and docs for the LTS. LTS: After three cycles of high pulse and intense work on features, this is a good time to catch our breath. It is a time for philosophy, debating and figuring out what the future should be like. These are of course just some ideas, but I think it's very important that users know what to expect. Karmic has been labeled "ME of Ubuntu" and "Vista of Ubuntu", etc. The reason is not that Karmic is bad, it's just that the expectations were sky-high without the users knowing about the big changes behind the scene. This is really bad marketing. Yes, this is free software, but more users still mean higher potential, and higher potential means more effort. What do you think? Jo-Erlend Schinstad -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Congrats on karmic, looking forward lucid
On Thu, 2009-11-05 at 22:38 +0100, Sebastien Bacher wrote: > Le jeudi 05 novembre 2009 à 23:37 +0530, Bryan Quigley a écrit : > > Empathy is much more limiting than I initially thought, and far less > > useful than promised. Maybe when telepathy is actually used by > > anything else it will become useful > > Hi, > > Could you give some details on that statement? It should allow to use > the same protocols, send files on standard ones and do video calls, > which other feature should we work on next cyle? > Sebastien Bacher Text formatting. Empathy doesn't process bold, color, font, size, etc. It also doesn't allow the user to insert a URL with text other than the actual address. Empathy also doesn't allow grouping buddies together into a "logical" contact as Pidgin does. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Congrats on karmic, looking forward lucid
On Thu, Nov 05, 2009 at 08:00:27PM +0100, Martin Pitt wrote: > Bryan Quigley [2009-11-05 23:37 +0530]: > > Maybe, I'm just being to optimistic but I plan on starting to roll out > > Karmic to my users later next week. > > Conversely, I'm probably too pessimistic here since I have just dealt > with SRUs and bug reports all the week. :-) Same... but I upgraded my wife last weekend from hardy, through intrepid, jaunty, and to karmic. I was surprised there weren't any significant problems (a few cosmetic changes that bugged her, but more because they changed rather than that they were bad). Bryce -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Congrats on karmic, looking forward lucid
Le jeudi 05 novembre 2009 à 23:37 +0530, Bryan Quigley a écrit : > Empathy is much more limiting than I initially thought, and far less > useful than promised. Maybe when telepathy is actually used by > anything else it will become useful Hi, Could you give some details on that statement? It should allow to use the same protocols, send files on standard ones and do video calls, which other feature should we work on next cyle? Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Congrats on karmic, looking forward lucid
Bryan Quigley [2009-11-05 23:37 +0530]: > Maybe, I'm just being to optimistic but I plan on starting to roll out > Karmic to my users later next week. Conversely, I'm probably too pessimistic here since I have just dealt with SRUs and bug reports all the week. :-) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Congrats on karmic, looking forward lucid
Bonjour, Sebastien Bacher [2009-11-02 14:45 +0100]: > Karmic has seen lot of technologies changes (new gdm codebase, > pulseaudio required by GNOME, empathy by default, devicekit-disks and > devicekit-power used in GNOME, etc) so it was expected it would have > some rough edges. Indeed, with so many things that changed it's a miracle that it works in the first place. In retrospect I think we should have announced it differently, as a "tech preview" release, and not recommend everyone to upgrade.. > - let's not spend too much time on backporting changes to karmic, using > the next 2 weeks to look at the user feedback, do stable updates to fix > the most annoying issues until UDS and then move our focus to Lucid Full ack. > - try to be conservative in the changes which will land in lucid, GNOME > upstream will likely rework some component in the GNOME3 optic and other > teams or upstream will probably keep working on changes to improve the > user experience, while the work they do is great it would probably be > good to wait until lucid+1 to bring those in the default installation. > I expect we will have some of those discussions at UDS too I just created the initial list of blueprints for lucid which were requested: https://blueprints.launchpad.net/ubuntu/lucid/+specs?searchtext=desktop There are some new features there, but a lot of them is "review"/"cleanup" type of work as well. We might have to drop some goals, though (the low/medium ones) in favor of working on bug fixes. > - the new gdm doesn't allow to do xdmcp from the login screen Sounds like this deserves a good bug report. > - the new gdmsetup doesn't allow to turn off the login sound which is > annoying when you want to boot your computer in library school Covered in blueprints. > - empathy deals with some protocols in a non optimal way Too fuzzy, but sounds like these should become bug reports. > - the new GNOME audio capplet and pulseaudio have limitations, without > starting discussions on pulseaudio again it would be nice to know > earlier what options the user interface should allow to tweak and > doesn't now for example This also works better with bug reports than a blueprint, I think. > - desktop login speed Covered in blueprints. > - the screensaver handling and inhibition is less than optimal Should be bug reports. > - lot of other small issues which are not stoppers but make the daily > user experience less good that it should Also bug reports. > One thing which would be nice to try this cycle is to have people > responsive to make sure a software or feature keep working as it should, > some examples: users switching, screensaver and inhibitors, > working as expected, cd dvd recording, rhythmbox (or > banshee) handling audio players correctly, GNOME automounting working, > etc. We have some of those broken every cycle and sometime user testing > doesn't raise issues until late in the cycle, if we could have some > people doing some testing at each milestone during the cycle on things > they are interested in it would probably have a good impact on the next > version stability. That sounds like a very good idea. In the ancient past we had a "laptop testing team", perhaps we should try to build a "desktop testing team", where each of the members "adopts" their favourite bit of the desktop (be that music player handling, photo import, scanning, beamer support, or whatnot)? Perhaps over time we can collect a series of "desktop test cases" which documents which bits we really want to work, and what particular things to test. We once started to collect "experiences" in the wiki: https://wiki.ubuntu.com/DesktopTeam/Experiences , which might be a good basis for this. Thanks all, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Congrats on karmic, looking forward lucid
Hey everybody, Karmic is available now and I would like to thanks everybody who worked on making it a great desktop experience for our users. This new version, as every Ubuntu version, is the result of combined efforts from lot of different people, users who tested our changes and gave feedback on those, upstreams who write most of the code we are using, translators, packagers, bugs triagers and many others not listed there, thanks to all of you. Karmic has seen lot of technologies changes (new gdm codebase, pulseaudio required by GNOME, empathy by default, devicekit-disks and devicekit-power used in GNOME, etc) so it was expected it would have some rough edges. Looking through the recent feedbacks we got, while karmic is working nicely in many cases and looking great, it also has an increasing number of annoyances, things which used to work and got broken on the way, etc. The next Ubuntu version will be a LTS and I think now is time to focus on bringing the stability back and tackling those annoying issues which added during recent cycles. To work toward this goal I would like to suggest that we do several things: - let's not spend too much time on backporting changes to karmic, using the next 2 weeks to look at the user feedback, do stable updates to fix the most annoying issues until UDS and then move our focus to Lucid - try to be conservative in the changes which will land in lucid, GNOME upstream will likely rework some component in the GNOME3 optic and other teams or upstream will probably keep working on changes to improve the user experience, while the work they do is great it would probably be good to wait until lucid+1 to bring those in the default installation. I expect we will have some of those discussions at UDS too - start early to list and milestone issues we want to see fixed for karmic, some will probably need blueprints and non trivial changes it would be good to have those on the map for UDS Some example of topic raised by users: - the new gdm doesn't allow to do xdmcp from the login screen - the new gdmsetup doesn't allow to turn off the login sound which is annoying when you want to boot your computer in library school - empathy deals with some protocols in a non optimal way - the new GNOME audio capplet and pulseaudio have limitations, without starting discussions on pulseaudio again it would be nice to know earlier what options the user interface should allow to tweak and doesn't now for example - desktop login speed - the screensaver handling and inhibition is less than optimal - lot of other small issues which are not stoppers but make the daily user experience less good that it should Those are random examples of things we might want to look at now to define what we want to do for lucid. One thing which would be nice to try this cycle is to have people responsive to make sure a software or feature keep working as it should, some examples: users switching, screensaver and inhibitors, working as expected, cd dvd recording, rhythmbox (or banshee) handling audio players correctly, GNOME automounting working, etc. We have some of those broken every cycle and sometime user testing doesn't raise issues until late in the cycle, if we could have some people doing some testing at each milestone during the cycle on things they are interested in it would probably have a good impact on the next version stability. What people think about those? Do you agree on the focus and goals for the next cycle? What do you think should be the workflow to suggest bugs that should be worked in karmic? Are you interested in doing testing on some desktop components along the cycle, how should we build a list of things which need testing? Should that be discussed on the list or during an IRC meeting, at UDS, just be on a wikipage? Thanks for reading this email, I'm waiting for your comments on the list and looking forward a great LTS cycle Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
