<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.ubuntu.devel.desktop">
    <title>gmane.linux.ubuntu.devel.desktop</title>
    <link>http://blog.gmane.org/gmane.linux.ubuntu.devel.desktop</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3889"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3886"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3885"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3871"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3858"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3856"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3855"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3845"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3844"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3842"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3841"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3840"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3839"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3838"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3837"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3828"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3812"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3811"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3810"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3809"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3889">
    <title>Visual Design Assets</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3889</link>
    <description>&lt;pre&gt;Hello,

We were talking about project management today and how to get work items
on the list for needing visual design.  Previously we have assigned
tasks and bugs to design, or individual designers, but in talking with
Nick what he'd prefer is that we assign those tasks and bugs to him --
and he'll ensure that they stay up-to-date with their internal list of
tasks.

He claims his e-mail inbox can handle the task ;-)

So, in the future, if you could please do that hopefully it'll result in
better coordination of work items.

--Ted

&lt;/pre&gt;</description>
    <dc:creator>Ted Gould</dc:creator>
    <dc:date>2012-05-22T19:49:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3886">
    <title>[Desktop UDS topic] Regional/national applications</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3886</link>
    <description>&lt;pre&gt;As I understand it, several countries have "special apps", that are very 
useful to that country.

As an example, for Sweden, we have BankID, which is used to log on to 
several government sites, declaring taxes etc.

Other countries have other favorites which are local to that country but 
still very important to have. I've heard Brazil has something similar 
but different, for example.

The degree of Linux support of these are of course varying, but in the 
BankID case there is a Linux version, but it could be easier to install, 
if we could get it into either Ubuntu Software Center as an app, or 
maybe into the partner repository. That would also bring the advantage 
of automatic updates, which would be attractive to the app developer (in 
the case of security related applications, even more so).

So, how do we
  - Identify what applications are important for a particular country?
  - Reach out to the developers of that application?
  - Help them out with integrating their apps into Ubuntu?
  - Get them into Ubuntu Software Center, the partner archive, or 
something similar?

The LoCo teams could be a valuable resource here, I assume.

&lt;/pre&gt;</description>
    <dc:creator>David Henningsson</dc:creator>
    <dc:date>2012-05-02T09:36:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3885">
    <title>(unknown)</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3885</link>
    <description>&lt;pre&gt;http://www.maquinavisual.tv/portafolio.old/wp-content/plugins/extended-comment-options/mylove.php?instrument143.jpg&lt;/pre&gt;</description>
    <dc:creator>Prudhvi Tella</dc:creator>
    <dc:date>2012-04-27T12:58:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3871">
    <title>[Desktop 12.10 Topic] Application startup time (AKA "Please use myRAM!")</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3871</link>
    <description>&lt;pre&gt;Application startup time is unnecessarily slow in a large number of
instances. Can we see some improvement in that area in the Q cycle? The
price of RAM has dropped dramatically, and usage has not increased all
that much. Can't we use it for something when it's available?

We now have Zeitgeist. This means we can know what users will do after
login. It's possible to tell not only what applications will be started,
but also what files will be used. In many cases, there's only a single
human user in the system. I would really like it if I could set my work
desktop to boot automatically in the morning, and it'd load my stuff
into RAM while waiting for me to log in. There's also a few websites I
always check first thing while I have my first cup of coffee. Load them
too so I don't have to wait for it. I'm the only human user on my
desktop, so why not log me in automatically, but in the background,
keeping the login screen as it is?

To my mind, these are all attainable goals:

* Sub-second login
* Instant loading of frequently used applications
* Zero-delay access to most frequently used websites.

Everyone is telling me to go buy a fast SSD. But that's expensive and in
my case, it doesn't provide any benefits that can't be achieved by
software. RAM is extremely cheap, and much faster than any SSD on the
market. What currently happens is that the login screen sits there
idling, waiting for me to pay attention to the computer before it starts
doing work it knows I'm going to want it to do. That's rude, isn't it?

In networked environments of diskless desktops, such as schools and
offices, the effects can be even greater. It might not be possible to do
background logins for the user, but a lot of things can still be loaded
in advance, providing a significantly improved experience. And of
course, the older the computers are, the greater the effect will be.

Jo-Erlend Schinstad

&lt;/pre&gt;</description>
    <dc:creator>Jo-Erlend Schinstad</dc:creator>
    <dc:date>2012-04-21T21:13:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3858">
    <title>[Desktop 12.10 Topic] System compositor</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3858</link>
    <description>&lt;pre&gt;Hi,

A change I'd like to make for 12.10 is to use a compositor to control
video from boot to shutdown.

This gives us the following benefits:
- We can have smooth transitions from the splash screen to the greeter
to the session and back again
- We don't use VT switching anymore which has been shown to be problematic
- We use one consistent monitor layout for all stages of the boot
- We can use the greeter as the lock screen (couldn't get it to work
this cycle for the above reasons)
- We can ensure that you can never accidentally switch to a locked session
- We can show the greeter while the session loads

The technology used will probably be Wayland, and in some ways this
change is to implement the Wayland Tech Preview that was proposed for
Precise [1].

Note that not all video drivers will support this, and we will continue
to support the current system for those that do not support it
(primarily the nvidia driver).

--Robert

[1]
https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-wayland-tech-preview

&lt;/pre&gt;</description>
    <dc:creator>Robert Ancell</dc:creator>
    <dc:date>2012-04-19T11:15:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3856">
    <title>[Desktop 12.10 Topic] Replace system-config-printer by the GNOMEprinting panel</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3856</link>
    <description>&lt;pre&gt;Hey,

That's somewhat a "leftover" from this cycle, I know Lars has been 
working on getting the GNOME tools at feature parity, or at least to be 
useful enough to be able to use it instead of the system-config-printer 
gui, he was close of having it ready this cycle so I guess it should be 
fine for next cycle. Not so much desktop work there I guess since Lars 
and Till should have that under control...

Sebastien Bacher

&lt;/pre&gt;</description>
    <dc:creator>Sebastien Bacher</dc:creator>
    <dc:date>2012-04-19T10:32:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3855">
    <title>[Desktop 12.10 Topic] GNOME plans review</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3855</link>
    <description>&lt;pre&gt;Hey,

Not sure how much we need to discuss but it's always good to have a 
GNOME checkpoint session.

It's likely that this cycle we will not "hold back" on things we kept 
behind until now, which means we need to bring clutter on the CD and see 
how we do that and what it means (do we need extra testing on some 
platforms during the cycle, how will it work for people not having 3d 
working, etc).

Some other desktopish topics I would like to discuss, not sure if that's 
the right session but since we will probably have time in that one:

- our delta with upstream and Debian and how we could lower it? mpt 
suggested that "launchpad-integration" items are quite "geeky", they 
also create most of our diff over Debian and extra work and don't really 
"scale" since they require sources patching, maybe it's time to 
discussion dropping that?

- tools, though UDD didn't change a lot so I don't think the consensus 
will be any different from what it was other cycles

- whatever other topics you guys come with ;-)

Sebastien Bacher

&lt;/pre&gt;</description>
    <dc:creator>Sebastien Bacher</dc:creator>
    <dc:date>2012-04-19T10:28:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3845">
    <title>{Desktop 12.10 Topic] Holistic approach to Ubuntu documentation</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3845</link>
    <description>&lt;pre&gt;I think it's necessary for Ubuntu to take documentation to another level.

When I first started with Ubuntu, I really wanted to learn how it all
fit together. I have used computers most of my life so I'm accustomed to
reading documentation and I was perfectly willing to dive right in. But
it just wasn't that easy, not necessarily because of the information
itself, but because of how it was organized and presented. There were no
clear starting point and no trails to follow. There were broken links on
wikis, and outdated information lying around. Much of the documentation
would only use version numbers, and have no easy way to see when it was
last updated, or if it had been superseeded. Confusion reduces peoples
ability to learn.

To me, this is The Issue with Ubuntu. If we're really going to succeed
in taking Ubuntu «across the chasm», then we must make it easy for the
curious to become users and for the enthusiasts to become power-users.
For this to happen, we need to do something drastic about the way
documentation is presented. I think Ubuntu Documentation must:

* Have an obvious starting point
* Lead to the next step
* Be instantly recognizable as valid or invalid
* Be grouped when applicable
* Primarily focused on LTS
* Reviewed for each release (hence the point above)
* Easy to contribute to by reporting issues
* Be not only API docs, but contain readable text.

developer.u-c and help.u-c has improved a lot in this regard, but not
enough. Look at this page first:
http://developer.ubuntu.com/resources/platform/api/12-04/. As a reader,
I can come across issues that I'm not able to read, but will help
improve the documentation. I should have a very easy way to report it.
There's no way at all on that site, though at the very bottom, I can
submit a tutorial.

Another example, look at this page:
http://developer.ubuntu.com/api/ubuntu-12.04/python/Unity-5.0.html.
Right, but that's Ubuntu 5.0. I was looking for 5.10. Is this still
valid? There's no way to know. We shouldn't rely on people to trust that
if not stated otherwise, it is valid. This is the web. There are
millions of old and unmaintained documents out there. It must be obvious
that it is valid. This also helps anyone recognize invalid
documentation, enabling them to report it or fix it.

And what if my primary focus is developing an application for LXDE and I
want to use only an indicator? In this specific case, I'd use a separate
version for the API docs and call it Unity Specification 1.0 for 12.04.
Then if there are any changes between now and 14.04, I'd call that 2.0.
For versions in between I'd add 1, 2 or 3. So, if there are API changes
i 13.04, I'd expect to find a Unity Specification 1.2 and that it would
clearly show the differences between 1.2 and 1.0, considering the newest
LTS the 

In the case of Unity-5.0 for Python above, I'm not sure I'd call that
Documentation. That is the convention, but I'm not sure that's what
people expects. I'd call that document a Specification. For
Documentation, I would expect more readable text, explaining what it's
for and how it is used.

Enum: Unity.FilterRenderer
CHECK_OPTIONS_COMPACT 4

Right. How do I use it? .)

Jo-Erlend Schinstad











&lt;/pre&gt;</description>
    <dc:creator>Jo-Erlend Schinstad</dc:creator>
    <dc:date>2012-04-19T00:39:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3844">
    <title>[Desktop 12.10 Topic] Quality,testability for the desktop components</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3844</link>
    <description>&lt;pre&gt;Hey,

The Canonical upstream teams did some good progresses on testing and 
quality this cycle, that's a good step for the Ubuntu Desktop quality, 
we still rely on quite some components from other upstreams though that 
didn't engage into a such process yet though (those who looked at 
gnome-settings-daemon, nautilus, gvfs, etc bugs on launchpad probably 
know what I mean there). I would like to see if we can work on our side 
and with upstream to get those automated tested in some ways.

It would be also nice to see regular run and report of the testsuits for 
other components which already have one (i.e glib, gtk) and some testing 
of their rdepends before upload.

Cheers,
Sebastien Bacher

&lt;/pre&gt;</description>
    <dc:creator>Sebastien Bacher</dc:creator>
    <dc:date>2012-04-18T08:39:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3842">
    <title>[Desktop 12.10 Topic] Login speed improvements</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3842</link>
    <description>&lt;pre&gt;Hey,

Yet another leftover from precise, not much to discuss as well, rather a 
"just do it". We did a bit of work this cycle but didn't go far, there 
is still room for improvement especially with nautilus, compiz.

Cheers,
Sebastien Bacher

&lt;/pre&gt;</description>
    <dc:creator>Sebastien Bacher</dc:creator>
    <dc:date>2012-04-18T08:22:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3841">
    <title>[Desktop 12.10 Topic] Old libraries cleaning</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3841</link>
    <description>&lt;pre&gt;Hey,

Not so much a discussion topic that a just do it, but I think we might 
get close of dropping pygtk, gtk2 and gconf from the CD so maybe let's 
see how much progress we can do this cycle with that?

Cheers,
Sebastien Bacher

&lt;/pre&gt;</description>
    <dc:creator>Sebastien Bacher</dc:creator>
    <dc:date>2012-04-18T08:20:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3840">
    <title>[Desktop 12.10 Topic] Deprecate language-selector</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3840</link>
    <description>&lt;pre&gt;Hey,

That's a leftover from precise but it would be good to use the upstream 
"region" panel code and deprecate language-selector next cycle (better 
to have capplets integrated in system settings that those "launchers" 
for standalone apps there).

We will maybe need some design input on the ui and to finish the coding 
part started this cycle.

Cheers,
Sebastien Bacher



&lt;/pre&gt;</description>
    <dc:creator>Sebastien Bacher</dc:creator>
    <dc:date>2012-04-18T08:12:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3839">
    <title>[Desktop 12.10 Topic] The future of third-party driver installation</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3839</link>
    <description>&lt;pre&gt;Hello Desktop fans,

We have had Jockey for quite a while now to perform the installation
of proprietary (e. g. NVidia), alternative (e. g. fglrx vs.
fglrx-updates), third-party (e. g. from openprinting.org) drivers.

However, I feel that this needs some refreshing:

 * The code base of Jockey is quite complex, it was meant for a lot
   more stuff than we are actually using it for. We also came up with
   simpler ways of mapping hardware to packages, mostly with
   additional tags in the apt package lists. We also have a more
   upstream friendly API in PackageKit/aptdaemon now to do this kind
   of thing.

   We can simplify the jockey code base and backend logic a lot (up
   to the extend of completely dropping it) by making full use of
   above new technologies and dropping the extra features we don't
   use. The exception is the openprinting.org detection, but that
   could go into system-config-printer or python-cups directly.

 * We install some drivers (like Broadcom wifi) straight from Ubiquity
   now, which certainly makes sense for devices where there is no free
   alternative. For the others (e. g. NVidia) we pop up a notification
   and offer to install them. I'd like to walk through the current UI
   and discuss how this could be made more steamlined and less
   confusing (e. g. for NVidia it can potentially offer 6 different
   drivers for you!)

 * We might consider merging the jockey UI functionality, which is
   mostly a shallow GUI around "install that package" now) into
   software-center, control-center, or something similar to the codec
   installer. I'd again appreciate if someone from the design team
   could participate in that (hello Matthew!).

Thanks,

Martin

&lt;/pre&gt;</description>
    <dc:creator>Martin Pitt</dc:creator>
    <dc:date>2012-04-18T07:14:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3838">
    <title>[Desktop12.10-Topic] Keybindings health check</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3838</link>
    <description>&lt;pre&gt;Hey guys,

We had tried to get some shortcut changes during the Precise cycle. Some 
successfully, some were not (like changing the "change worspace " 
keybindings).

I propose a healthy check session/discussion with the design team to see 
what changes will be done for 12.10, what we need to expose on 
gnome-control-center, reviewing what we already expose there. Also, what 
changes are needed on the window manager side to propose more than one 
(configurable) keybinding to not break past conventions with new 
proposed ones.

Thanks,
Didier

&lt;/pre&gt;</description>
    <dc:creator>Didier Roche</dc:creator>
    <dc:date>2012-04-18T06:37:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3837">
    <title>[Desktop12.10-Topic] User configuration change after package upgrade</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3837</link>
    <description>&lt;pre&gt;Hey everyone,

I know that will sound like a deja-vu for some of you (we did discuss 
about it at UDS Brussels IIRC), however I think the situation nowdays 
will make it more needed than what it was in the past.

Sometimes, we need to change/update some user configuration on upgrade. 
However, as everyone knows, the upgrade/installation phase is proceeded 
by root, so we dont have a sane and secured access to all user data on 
this machine at this particular time.
Of course, there is still the gold rule "don't change user configuration 
on upgrade" that we try to keep as much as possible, and in this case, 
changing the gsettings default is just enough most of the time. However, 
some cases are still valid and changing the gsettings default doesn't 
work, on top of my head:
- Unity launcher icons. Some softwares renames their .desktop file name 
(ubuntu one for instance) in newer release. The key for those icons are 
put together in a list ["firefox.desktop", "ubuntuone.desktop"], and so 
if ubuntuone.desktop is renamed after a system upgrade, the launcher 
will just drop ubuntuone.desktop but not showing the new one. An upgrade 
to detect that case and replace ubuntuone.desktop with the new name will 
be handy.
- We got the glorious example on compiz in the past. Fortunatly, this 
one will soonly be fixed with the case of gsettings, but we surely do 
have other similar cases when a default is reset to the default and not 
considered as such.
- Even if compiz is fixed, we needed to change the default plugin list 
more than once, depending on which profile is running, that's another 
use case.

So, I want to open the discussion on how to do this in a light and 
harmless way (no python for instance ;)). Stamp that a migration 
happened. Should this be some triggered by client packages themselves? 
When should this be run in the session? and so on :)

Cheers,
Didier

&lt;/pre&gt;</description>
    <dc:creator>Didier Roche</dc:creator>
    <dc:date>2012-04-18T06:32:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3828">
    <title>[Desktop12.10-Topic] Awareness of existing user configurations insoftware feature upgrades</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3828</link>
    <description>&lt;pre&gt;Dear Friends,

There is a problem, in my opinion, a conceptual one, with user
configurations -those that are in home directories-, and, well, their
software's upgrades.

In some scenarios, this problem, which I will better define below,
causes crashes. In others, it causes missing features in the software.

I'm sure that there are many problems that this can cause and indeed
causes in practice. I have personally experienced bugs that arise from
this issue and I won't be surprised if every single one of you had
such encounters, as well.

I'll give you the most common proof of this problem. Do you ever get
the feeling that if you'll make a new user account for yourself then
everything is going to be so much nicer in your UX? I bet that KDE
users are jumping up and down within themselves now because in KDE
there's so much configuration options that this is exacerbated.

Let me give you one recent example[1], which is such a serious one,
albeit in a non-critical software, but it stands in it's own right.
(Please note that I've not tested this one yet but it does demonstrate
one aspect of the problem and even if it turns out to be a different
bug, it would demonstrate the idea.)

And do you ever get the feeling that there are too many configuration
files in your home directory, anyway? "Did I really create all that
configuration datum?" I ask myself.

And let me ask you another thing to demonstrate the issue. The
commonality of it. Have you ever fixed a bug in a software, or rather,
worked around it, by removing it's configuration entirely? Does the
phrase 'rm -r .config/&amp;lt;rampant-software&amp;gt;' look familiar?

Here's another example which I solved quite exactly in this way[2].
Worked around, rather.

I'm not a software developer. I'm an avid user of Ubuntu and a Free
Software Ideologist. I won't tell you, developers how to write your
software, or, rather, our software.

I'm just here to point out something that's been bothering me (us, I
hope) for a while and I hope that we can start to put an end to this
at the current development cycle and that it would make a standard and
echo this standard outside into the Free Software Stratosphere.

So, I suggest two things as a start. One, is to find a pattern in
this, or a pattern of patterns because this is a multifaceted problem.
And to be precise, I'm not talking about system software
configurations, like in '/etc'. I'm only talking about what's inside
our homes.

In order to find patterns, I suggest that we first start to tag these
bugs as 'configuration-upgrade' such as in this list[3].

Then, we can categorize them according to the type of mistake that was
made by the developer ("oh my gosh, he didn't really say that!"). We
need to admit that there's a problem here, OK?

For this purpose, I've made the Wiki page ConfigurationUpgrade[4]. In
it, I'm currently writing some more guidelines which I'm making up.

This research will help bring the awareness of the subject into the
God-given, electronic minds of the developers.

The second thing that I suggest is testing, testing and you know what
else. Testing. The fact that so many of these bugs "get away with it"
and flow into our releases is staggering. Perhaps "after-upgrade"
testing and not only ISO testing is required.

Please chime in with your thoughts but keep in mind that there might
be some old configuration files lurking, so be careful!

Thanks and Blessings,
Shahar

  1. https://bugs.launchpad.net/ubuntu/+source/byobu/+bug/973638
  2. https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/963125
  3. https://bugs.launchpad.net/ubuntu/+bugs?field.tag=configuration-upgrade
  4. https://wiki.ubuntu.com/ConfigurationUpgrade

&lt;/pre&gt;</description>
    <dc:creator>Shahar Or</dc:creator>
    <dc:date>2012-04-04T20:30:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3812">
    <title>Upload rights for desktop-extra-set</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3812</link>
    <description>&lt;pre&gt;-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

I am Rico Tzschichholz and have done some work regarding the GNOME3
packaging. I am working on publishing a gnome-shell package-set since
its early states in my Testing PPA and since Natty in the Gnome3-Team
PPA and Debian.

It would be great to have upload rights for desktop-extra-set which will
give me the opportunity to update and fix things directly in Ubuntu.

Please have a look at my profiles for further information:
[1] https://wiki.ubuntu.com/ricotz
[2] https://launchpad.net/~ricotz

Best Regards,
Rico Tzschichholz
ricotz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPdWDpAAoJEF3s26iScOcjH9QQALOFIEy0svyQQUQ22p0S9791
Vb81mVKNgMujWCWkrBswL+2IEk5lyaO271pLa8dTAMuojDF0es6tE/9aKUvkcyJ+
SEXtGHvHwO47EGgwOnWdE/grJH2XXyPaDURz13EJdxHB8FEAquOqxZTs6K2A+bLD
DNDHnLjeV7UB1iWRHQO4ZO4n8uvjSIzcKAm1aqwAQmDb5x6AT8HHKElvJd4o0zRQ
9abCXM+Ha1BJ5zL1YHcvLqoZ0/Gvqk0q7JW/p5YEne9sAxkrJtKZ8fk85tNsuTzl
Ke/XDYbfcdvjexLctO9HsOSZNIrEg4zofXMhku9Y87v/OG1yft6TY/fSGTORofYZ
0XfT+qaJwA8wy1FnYI3vhloI0RMCh9t2IPLKucnFoWLr3l9l7vPDAx5ZiPg9x+KX
cjixejckhqD7ISCDJCOFtd7ZPEimuawmbbo2x5z3kBSodZ0PY7RdOJCIARKOKMvb
uYaiOjKdbMMZr02WjtiGxKH5gxhXvzL8FHn9POLe+oD/gp1imSQ+LuVJEgl+unWY
1KPgYas5cemsy9HhFb6q+uuTelJIoxsjbHd32METeOqrCqrl2/khGwh3Lusfdiw5
tx73oXcGy6aV9suTykMpYdWD48PCpPB2oXah8XQuVdbQXU4Ol8ZYPAl8aEXvOypK
2ne9I6uqy20iH5sFd+8b
=R76G
-----END PGP SIGNATURE-----

&lt;/pre&gt;</description>
    <dc:creator>Rico Tzschichholz</dc:creator>
    <dc:date>2012-03-30T07:29:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3811">
    <title>[Desktop12.10-Topic] Default application selection process</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3811</link>
    <description>&lt;pre&gt;Hi there,

This is my proposal for a UDS discussion. I haven't really formulated
any ideas about how this should work, but I think there's something here
to talk about. This mail also isn't as structured as it could be, but I
hope there's something worth discussing in here.

There isn't really a process for selecting the applications we install
on the desktop images by default. Typically someone proposes a change
and sets out their reasons and if there is enough consensus then the
change is made.

One problem is that there is usually one 'winner' and a number of 'losers'.
Especially when defaults are switched (Evolution to Thunderbird, F-spot
to Shotwell, Rhythmbox to Banshee to Rhythmbox), people on the 'losing'
side are prone to feeling hard done by if they consider that the
decision has not been made fairly.

Obviously my most close involvements around this topic are the recent
media player switches. I'll outline some of the issues from the
perspective of the 'loser'. Please don't turn this into a technical
debate on this specific change; I want to keep the discussion around the
process.

  - Upstream (and some Ubuntu developers) were caught by surprise that
    this option was being considered. Subsequent conversations
    indiciated that this topic came up by surprise in the session.
  - Bugs which were considered a distro priority were not communicated
    with upstream.
  - The etherpad from the session was seen to be the record of the
    discussion and contained a lot of disappointing misinformation. It
    got spammed/trolled quite a lot as a result of the publicity.
  - The outcome from the session was very widely perceived as a final
    decision for the release, when in fact it was not intended to be. I
    don't think this was helped by the wording used in the closing
    plenary [1].
  - After the fact there was a discussion on this mailing list but the
    final decision[0] was taken by a manager at Canonical. It's not
    clear to me whether this was the right thing to happen, rather than
    the decision being made by the entire desktop team.

Hopefully others have thoughts about how this can work better. The main
issue I think is to allow all stakeholders ample opportunity to make
their representations, but the issue around how the decision is actually
finally made is also worthwhile IMHO.

Cheers,

&lt;/pre&gt;</description>
    <dc:creator>Iain Lane</dc:creator>
    <dc:date>2012-03-30T10:00:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3810">
    <title>GNOME 3.4 packages in Ubuntu 12.04 "Precise Pangolin"</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3810</link>
    <description>&lt;pre&gt;Hi everyone.

I'm currently working on an Evolution plugin named evolution-kolab [0],
which connects Evolution to the Kolab2 groupware server [1]. Version
3.4.0 of evolution-kolab was the first to be released under the hood of
GNOME (development had previously taken place at SourceForge).

Since Evolution 3.4 will not be shipped with Ubuntu 12.04 "Precise Pangolin"
(it is version 3.2 which is being shipped, if I'm not mistaken), I have
checked with the "GNOME3 Team" [2] for pre-built packages of Evolution and
Evolution-Data-Server 3.4.0 for Precise, but so far, found none in the
launchpad PPA.

Do you have any plans of providing packages for Evo, E-D-S and maybe even
evolution-kolab via this PPA? It would help me much, in that I can have
more people testing evolution-kolab before the release of 3.4.1, in which
I would like to incorporate as many bugfixes as possible.


Kind regards,

Christian


[0] https://live.gnome.org/Evolution/Kolab
[1] http://www-old.kolab.org/about-kolab-clients.html
[2] https://launchpad.net/~gnome3-team

&lt;/pre&gt;</description>
    <dc:creator>Christian Hilberg</dc:creator>
    <dc:date>2012-03-28T16:22:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3809">
    <title>Privacy pane in Nautilus folder properties?</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3809</link>
    <description>&lt;pre&gt;The new privacy settings for Zeitgeist are cool and something I think 
many users will appreciate.

Would it be cool if we got a privacy pane in the folder properties in 
Nautilus? It would contain the possibility of encrypting the folder, but 
also choose whether or not activities in that folder should be recorded 
by Zeitgeist. It should also have a button to open the privacy applet in 
System Settings.

There might also be other privacy settings that affects folders.

&lt;/pre&gt;</description>
    <dc:creator>Jo-Erlend Schinstad</dc:creator>
    <dc:date>2012-03-28T11:52:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3808">
    <title>Ubuntu 12.10 Call for Topics</title>
    <link>http://comments.gmane.org/gmane.linux.ubuntu.devel.desktop/3808</link>
    <description>&lt;pre&gt;Hi all,

This is the call for discussion about Ubuntu desktop planning for the
12.10 cycle. Here's the process I'd like to use.

1. Send a call for topics from the Ubuntu desktop community (this is it)

2. Have an exchange over email on the ubuntu-desktop
channel/mailing list to discuss the requirements in depth.

3. Produce a resulting UDS plan which summarizes the topics going
into UDS, and feeds into blueprints

4. Provide a final roadmap post-UDS

Here is the schedule with some details.

= Today:  Request for Topics =
This email is the request for topics. Please send topics that you would
like the Ubuntu desktop team to consider for this cycle to the
**ubuntu-desktop** mailing list [1] with "[Desktop12.10-Topic]" in the
subject
line. These are not specific requirements, but high-level ideas or concepts.

Though we will want hear about all of your needs, while compiling
requirements, it may be useful to keep in mind that some requirements
are easier for us to fulfill than others, e.g.
 * Choice of specific versions of upstream packages or applications
 * Choice of specific applications to deliver by default
 * Getting packages into Universe or Main
 * Writing modest glue code to enable new scenarios or to integrate
functionality from different packages
 * Moving code that you already wrote or are going to write into the distro
 * Integrating patches from upstream bug trackers or similar
 * Enhancing projects for which we are upstream (LightDM/Unity Greeter,
Upstart, Ubiquity, etc....)


= Now through April 30th - Requirements discussions held =
We will discuss topics in the ubuntu-desktop irc channel and mailing
list. The goal will be to identify and document specific requirements.

= May 1st - UDS - Topics Review =
The week before UDS we will present a plan. This is essentially
a review of what topics we have planned for further discussion at UDS
in the form of approved blueprints.

= May 7th - May 11th - UDS =

= Approximately two weeks post UDS - 12.10 Plan Review =
About two weeks after UDS, we will revise the UDS 12.10 Plan to
capture what was actually decided as the plan of record at UDS, and
present that information.

Thanks all.

-Jason

[1] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
&lt;/pre&gt;</description>
    <dc:creator>Jason Warner</dc:creator>
    <dc:date>2012-03-28T01:34:11</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.ubuntu.devel.desktop">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.ubuntu.devel.desktop</link>
  </textinput>
</rdf:RDF>

