Congrats on karmic, looking forward lucid

Martin Pitt martin.pitt at
Wed Nov 4 14:26:38 GMT 2009


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

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,
> <empathy_protocol> 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: , which might be a
good basis for this.

Thanks all,

Martin Pitt                        |
Ubuntu Developer (  | Debian Developer  (

More information about the ubuntu-desktop mailing list