[Desktop12.10-Topic] Awareness of existing user configurations in software feature upgrades

Thu Apr 5 00:13:20 UTC 2012

Back when everyone had an xorg.conf and a lot of the X bugs were due to
malformed config files, we would collect the files and run them through
checkers.  Brian Murray ran a bot that'd test xorg.confs in bugs posted
to launchpad for instance.  Found quite a few issues that way.  These
days xorg.conf's are rare and hardly anyone hand-edits them so we don't
do this anymore (although maybe we should...)

But the concept could be applied more generally for config files of all
sorts.

The most effective thing you can do (IMHO) is create apport hooks for
every application that installs a config file, that looks for and
attaches that file when a user files a bug via 'ubuntu-bug package'.
The hooks are trivial python scripts, basically just:

    from apport.hookutils import *
    from os import path

    def add_info(report):
        if ui.yesno("Would you like to include your ~/.myconf?"):
            attach_file_if_exists(report, path.expanduser('~/.myconf'), 'MyConf')

[You can omit the yesno prompt if you're absolutely certain there's no
chance of sensitive info in the config file, or if you programmatically
strip out or hide that info.]

Copy your hook to /usr/share/apport/package-hooks locally, and test it
out yourself.  Once you have it working the way you think it should,
post it to the package's bug tracker (ubuntu-bug <package>), and make
sure to mark it as a patch.  A package maintainer will review and
incorporate it into the package.

Next, wait, and let a nice database of config files accumulate in
launchpad.

Then, run a launchpadlib script to download all the configs.  Weed out
all the dupes.  Keep track of the package version.

Now make a test that iterates through all the config files, launching
the program, and testing if it successfully loads or exits/crashes.
If the app has a test suite, bonus, run that too.

Finally, go file bug reports (both in launchpad and upstream) for the
failures that occur.

Bryce

On Wed, Apr 04, 2012 at 11:30:09PM +0300, Shahar Or wrote:
> 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/<rampant-software>' 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
> 
> -- 
> ubuntu-desktop mailing list
> ubuntu-desktop at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop