FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Desktop

 
 
LinkBack Thread Tools
 
Old 04-04-2012, 08:30 PM
Shahar Or
 
Default Awareness of existing user configurations in software feature upgrades

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@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 
Old 04-05-2012, 05:45 PM
Shahar Or
 
Default Awareness of existing user configurations in software feature upgrades

Dear Bryce,

On 5 April 2012 03:13, Bryce Harrington <bryce@canonical.com> wrote:
>
> 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.

This would be great. Promoting the use of Apport hooks is also generally good.

> 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.

Thank you for the idea and example, Bryce. I've added it to the wiki[1].

* 1. https://wiki.ubuntu.com/ConfigurationUpgrade#What_can_be_done.3F

Many Blessings,
Shahar

> 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@lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 

Thread Tools




All times are GMT. The time now is 12:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org