Re: Bugs reports should include syslog warnings or not?

[Matthew Paul Thomas]

Robie Basak wrote on 19/03/18 19:41:
>…> No, I think you have the inverse sense of what I intended. I mean
that> by the _developer_ choosing to write upstream code such that
something> is logged,
Ah, I see, I misinterpreted “one” as referring to the user.

>that developer is also implicitly deciding that the logs
> may be made public, because that's how the ecosystem works. So
> upstreams should ensure that private information is not logged by
> default.
>…
>> This seems to assume that the main use of Ubuntu log files is posting
>> in public bug reports and support forums — rather than, say,
>> troubleshooting and system administration in corporate IT
>> departments. Again, I’d be surprised if that’s true.
> 
> For a privacy concern, I don't think it matters what the main use is.
> A minority use that leads to a leak is still a leak that we should
> fix.

The proportion of use determines *how* it should be fixed. If many/most
uses of a log are for private troubleshooting and system administration,
then expecting every upstream developer to omit useful information when
logging — or to store “the private information somewhere
out-of-default-band” — would not be the most efficient solution.

-- 
mpt

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Bugs reports should include syslog warnings or not?

[Matthew Paul Thomas]

Robie Basak wrote on 19/03/18 13:47:
>
> On Sat, Mar 17, 2018 at 08:13:55PM -0400, Jeremy Bicha wrote:
>>
>> One particular class of private info I've seen in the systemd journal
>> is file names of files that tracker fails to index.
>>
>> File names can be very sensitive. And yet, it seems to me like it's
>> appropriate for tracker to log the file name as a warning.
> 
> The way I see it, by choosing to log, one is also choosing to make
> that data public should the user share logs. Since sharing logs is
> something that is typically done when asking for help on the Internet
> at large.

If I understand this correctly, the logic is:

1.  People choose whether to log systemd.

2.  Those people, who choose to log systemd, know that “ubuntu-bug
evolution” (for example) will post JournalErrors.txt publicly.

3.  Those people, who know they’re posting JournalErrors.txt publicly,
also know that it may include confidential information.

Is that right? Because I’d be surprised if *any* of those things is true
(for more than 10% of that set of people), let alone all three.

> apport is only one part of this. Special casing privacy considerations
> in apport, IMHO, doesn't help with any wider privacy leak when a user
> is asked to share logs some other way.
> 
> I conclude that it needs to be decided in tracker upstream if that
> information should be considered private or not. If it should be
> private, then it shouldn't be logged by upstream by default.
>…

This seems to assume that the main use of Ubuntu log files is posting in
public bug reports and support forums — rather than, say,
troubleshooting and system administration in corporate IT departments.
Again, I’d be surprised if that’s true.

-- 
mpt

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: More diagnostics data from desktop

[Matthew Paul Thomas]

Robie Basak wrote on 21/02/18 14:10:
>
> On Wed, Feb 21, 2018 at 12:18:35PM +, Matthew Paul Thomas wrote:
>>
>> Now, I’m not a statistician, so maybe I’ve made a silly
>> miscalculation or misunderstanding.
> 
> I'm also not a statistician. The assumption you're making is that the
> people who opt-in would be a representative sample of the whole
> population, and I think this is quite plainly not true.
>…

I’m not making that assumption. Originally I wrote, “making it opt-in
would give us results that were just as useful as making it opt-out,
unless the resulting sample was (a) too small to be useful or (b)
*too biased in some way*” (emphasis added). And when I’d calculated that
(a) almost certainly wouldn’t be an issue, I said, “If you were planning
to do any sub-sample analysis, *or reweighting for known biases*, then
the original sample would need to be bigger” (emphasis added).

It might be the case that for Ubuntu, opt-out is substantially biased
too, because the people who opt out are both numerous enough and
different enough from the rest.

If we’re going to tackle sampling bias, that’s great, but we should have
an actual mathematical plan for doing it. (For which, again, consult a
statistician.) Making it opt-out might be part of an effective plan, or
it might not.

-- 
mpt

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: More diagnostics data from desktop

[Matthew Paul Thomas]

Will Cooke wrote on 20/02/18 11:10:
>…
> We were thinking along the lines of something which would try to send
> the data at login a number of times, let's say 10, and then give
> up.  So if the machine never comes on line, then the data never gets
> sent.  If the machine travels between various locations before
> arriving at a working internet connection, then it should eventually
> be able to send it.  I think that would cover the vast majority of
> cases.

That seems reasonable.

>…
>> For example, if we could see how often people change their reported
>> location, we’d have info on how accessible the time zone UI should
>> be. And if it turns out that only a tiny fraction of Livepatch users
>> turn it on during install, vs. afterwards, that would influence
>> future installer design.
> 
> Wouldn't that involve us being able to track a person/machine to know
> when it had been changed?  Or would something in the location picker
> send a signal?  I don't like either of these options, I've probably
> misunderstood the idea.

Neither, I think. The location example would require Ubuntu to count how
often the setting had changed (for example, “2 changes in the past
month”). And the Livepatch example would require Livepatch to record
whether it had been configured in the installer or System Settings.

>>> Any user can simply opt out by unchecking the box, which triggers
>>> one simple POST stating, “diagnostics=false”.
>> 
>> What is the purpose of this?
> 
> To try and measure engagement rates.  This would be important in the
> "opt-in" case I think, how representative of users is the data?  < 10%
> of people are submitting data, then probably not very useful.
>…

A 10% response rate would be necessary, as far as I can tell, only if
there were fewer than 3460 Ubuntu desktop users in the world. Assuming
that you’re going for a 5% margin of error with 95% confidence level.

If there were, say, 4 million Ubuntu desktop users in the world, you’d
need only 385 submissions to reach that level of confidence. Even for a
more precise 2% margin of error, you’d need only 2400 submissions — that
is, you’d need only a 0.06% response rate. (This is why someone polling
a state/country, which has a million voters, doesn’t need 100 000
responses. Often they collect just 1000.)

As long as the number of Ubuntu desktop users is anything more than half
a million, the response rate is basically irrelevant: the required
sample size stays almost constant. For example, to get that 2% margin of
error from 500 000 Ubuntu users would require 2390 submissions, while
from 100 million Ubuntu users it would require 2401 submissions.

Now, I’m not a statistician, so maybe I’ve made a silly miscalculation
or misunderstanding. If you were planning to do any sub-sample analysis,
or reweighting for known biases, then the original sample would need to
be bigger. But if you were proposing that this be opt-out merely because
you thought we’d need a ≥10% response rate — or if you were proposing
“diagnostics=false” because you thought we’d need to measure the
response rate at all — then I’d strongly encourage consulting a
statistician first.

Cheers
-- 
mpt

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: More diagnostics data from desktop

[Matthew Paul Thomas]

Will Cooke wrote on 14/02/18 15:22:
>…
> We want to be able to focus our engineering efforts on the things that
> matter most to our users, and in order to do that we need to get some
> more data about sort of setups our users have and which software they
> are running on it.
> 
> We would like to add a checkbox to the installer, exact wording TBD,
> but along the lines of “Send diagnostics information to help improve
> Ubuntu”.  This would be checked by default.

I’ve just drafted a design for this.  It’s
basically a subset of the System Settings screen.

> The result of having that box checked would be:
> 
> * Information from the installation would be sent over HTTPS to a
> service run by Canonical’s IS team.  This would be saved to disk and
> sent on first boot once there is a network connection.

Information from the installation would be fascinating, for improvement
of the installer in particular. However, I don’t think it would give you
an accurate idea about the “sort of setups our users have”, for
improvement of Ubuntu in general. It could lead you to think that, for
example:

*   Internet connection is less common than it really is. (Because of
things like proxies, as mentioned by Ernst Sjöstrand, or
not-yet-installed wi-fi drivers. And because if people still can’t
get online later, they might uninstall Ubuntu and you’ll never get
a report.)

*   Wired Internet connections are more common than they really are.
(Because they’re being used temporarily during installation, while
wi-fi isn’t working.)

*   Typical screen resolution is lower than it really is. (Because
people don’t tweak the resolution until after installation. And
because if they fail to do so, they might uninstall Ubuntu,
resulting in a report for a system that soon stops existing.)

*   Bluetooth devices are much less common than they really are.

I think it would be much more interesting to measure these things month
by month.

>     The file
> containing this data would be available for the user to inspect.
> 
> That data would include:
>    * Ubuntu Flavour
>    * Ubuntu Version
>    * Network connectivity or not

If I understand “on first boot once there is a network connection”, that
would exclude devices that were offline until the second startup or later.

>    * CPU family
>    * RAM
>    * Disk(s) size
>    * Screen(s) resolution
>    * GPU vendor and model
>    * OEM Manufacturer
>    * Location (based on the location selection made by the user at
> install).  No IP information would be gathered
>    * Installation duration (time taken)
>    * Auto login enabled or not
>    * Disk layout selected
>    * Third party software selected or not
>    * Download updates during install or not
>    * LivePatch enabled or not
> 
> * Popcon would be installed.  This will allow us to spot trends in
> package usage and help us to  focus on the packages which are of most
> value to our users.

This effectively singles out .deb package installation as the only thing
that should be reported periodically, with everything else reported
one-off. Is that just for ease of implementation, or is there a reason
not to report the other things periodically too?

For example, if we could see how often people change their reported
location, we’d have info on how accessible the time zone UI should be.
And if it turns out that only a tiny fraction of Livepatch users turn it
on during install, vs. afterwards, that would influence future installer
design.

>…
> Any user can simply opt out by unchecking the box, which triggers one
> simple POST stating, “diagnostics=false”.

What is the purpose of this?

>   There will be a
> corresponding checkbox in the Privacy panel of GNOME Settings to
> toggle the state of this.
>…

This checkbox was implemented in Ubuntu 13.10 and later. I’ve just
tweaked the design to update the examples of metrics collected.


Juerg Haefliger wrote on 15/02/18 07:10:
>…
> Please make this an opt-in rather than an opt-out. This just smells
> like a trend towards a Windows/Android installation where you have to
> unset gazillions of check boxes to prevent the machine from posting
> your life to the vendor. We shouldn't go there.

The diagnostics checkbox was introduced in System Settings five years
ago. So if this “smells like a trend”, it’s a glacially slow trend.

One characteristic of “big data” is that users often can’t be expected
to foresee the kinds of ways the data can be combined in future. So if
there is a privacy problem, making collection opt-in won’t necessarily
solve it.

On the other hand, making it opt-in would give us results that were just
as useful as making it opt-out, unless the resulting sample was (a) too
small to be useful or (b) too biased in some way.

Cheers
-- 
mpt

-- 
ubuntu-devel maili

Re: Interested in Contributing

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

shuaib akram wrote on 19/07/15 07:46:
> 
> Hi All,
> 
> I want to contribute to ubuntu. Please let me know where I can
> start.
> 
> ...

Welcome! 

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlWvsgsACgkQ6PUxNfU6ecpDhQCfQttUYdLghAWChtQK6y9/e85t
WjAAoK3UVvpRdP1bxeeS80wvqtnaumPO
=ZOeK
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ease of enabling -proposed

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Murray wrote on 11/03/15 17:32:
> 
> Reviewing crash reports in the Ubuntu Error Tracker and bug
> reports in Launchpad, I've noticed quite a few tagged 
> "package-from-proposed". This tag is added by apport when the 
> installed package version is available from -proposed and not from 
> -security or -updates. I'm even seeing these from users of Vivid.

This is a symptom of "Too easy to activate the proposed repository"
.

However, those error reports should not be disregarded in error
tracker statistics. If some proportion of Ubuntu users turn on
- -proposed when they shouldn't, that is a real influence on the average
reliability of Ubuntu as people actually experience it.

> Evan suggested removing the "Pre-released updates 
> ($release-proposed)" checkbox from software-properties-gtk,
> thereby preventing accidental enabling of it.

In the design linked from that bug report, I replaced the checkboxes
with a menu containing three or four options:
*   "All updates" (the default, -security + -updates + -backports)
*   "Security and recommended updates” (-security + -updates)
*   "Security updates only" (-security)
*   "Custom" if current config is anything else, e.g. with -proposed.

This would also make it much harder for people to make mistakes like
having -backports turned on but -security turned off.

You could implement this change independently from the rest of the design.

> I think this should definitely be done for the development release
> of Ubuntu. I also think it would be a good idea for Stable
> Releases given that there is no indication in software-properties
> what any of the pockets are for and given that packages in
> -proposed are not regularly cleaned up so may contain packages
> which have either failed verification or not had the bug fix
> verified.
> 
> One argument I might have made for leaving the checkbox would be
> to make it easier for people to participate in the SRU
> verification process, but I don't having people unintentionally
> enable it is worth that.

I have a design for making that easier, too. :-)


- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlUBeg4ACgkQ6PUxNfU6ecrG0gCgzT3GkU+58V3/lK4TriHi/+aN
4ycAnR0x1q81QldIoMBGyyyNPCyjFywi
=0/xx
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marc Deslauriers wrote on 05/01/15 04:45:
> ...
> 
> So you agree with me that if you don't want your code to be 
> distributed as proprietary software, you shouldn't be contributing 
> to BSD or GPL-with-CLA software?

If you think proprietary redistribution of the work you contribute to
is a bad idea, the CLA is suboptimal because it gives Canonical that
option.

If you think proprietary redistribution of the work you contribute to
is a good idea, the CLA is suboptimal because it gives *only*
Canonical that option.

However, that inefficiency for individual contributors will sometimes
be less than the cost of developing/adopting a symmetrically-licensed
alternative. This is the case for Cups, for example (where only Apple
can redistribute proprietarily), but apparently has not been the case
for LightDM (where only Canonical can).

> Because big successful projects such as MySQL and Qt have _proven_ 
> that selling GPL exceptions is a valid model that advances the 
> quality of open source software.

Similarly, it is apparently the case for the MySQL fork MariaDB (where
only the MariaDB Foundation can redistribute proprietarily), while the
contemporary MySQL fork Drizzle (where no-one can) seems to have died.

> Honestly, I wish more software was like that.
> 
> I want the _default_ license when people write software to allow 
> access to source code. I want every single application I run on my 
> Android phone to come with source code. The only way to achieve 
> that is to stop trying to prevent developers from having a revenue 
> stream with their creation.
> 
> For example, why isn't the Ghostscript model good enough for open 
> source enthusiasts? I'd gladly give a timed GPL-exception in order 
> to get high quality software that isn't developed in a basement,
> or with VC money. I'd gladly accept that a certain piece of
> software is used in some proprietary product as long as a contract
> is in place that assures me that every single improvement makes its
> way to the GPL version.
> 
> As long as people criticize models that allow developers to invest 
> money in an open source software project without being able to 
> monetize their investment, we'll always live in a world where open 
> source software is the exception rather than the norm. That is not 
> why I have spent a large part of my life dedicated to open source 
> software. I am of the opinion that free licensing is superior, but 
> every time someone tries to come up with a business model that 
> allows developers to actually get paid to develop it, it gets 
> rejected by the very same community who want to see it thrive.

All that could be true, *and still* individual contributors would
rationally prefer, all else being equal, to contribute to a symmetric
project than an asymmetric one. It might be a tragedy of the commons:
collectively we're better off with asymmetric licenses, but individual
contributors are more effective contributing under symmetric ones.

Canonical recently released LXD under the Apache License, and
therefore without CLA. This will be an interesting data point for how
much the CLA is a real disincentive, and how much it is merely a
punching bag.


- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlSrwtMACgkQ6PUxNfU6ecqGcACgyHiC9UFeqPdXWi1rywqsAWGo
Fr4AoKs9LNmYjki1EQdFO7ix986lvtEz
=Jibk
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: errors.ubuntu.com and upgrade crashes

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Seth Arnold wrote on 16/05/14 22:07:
> 
> On Fri, May 16, 2014 at 10:38:35AM +0100, Matthew Paul Thomas 
> wrote: ...
> 
>> Mozilla has the resources to include this function. Perhaps the 
>> LibreOffice team does too. But it's neither reasonable nor 
>> elegant to expect every app to do it.
> 
> This is something we could provide to the developers as a simple 
> API. onApplicationUpdate: high-level signal or a simple C function 
> to install the inotify listener that can signal the application's 
> main event loop when appropriate. We probably even already have a 
> file in every package that could serve as the inotify sentinal.
> 
> That way, applications that are brittle about having their 
> resources updated 'from underneath' can be prepared to do
> something about it.
> 
> ...

A package's debian/control file can contain an XB-Restart-Required
flag. If it does, Software Updater will warn you ahead of time that
installing the update will require restarting the computer.

Software Updater could do the same for applications that require
relaunching. debian/control could contain a flag listing which
binaries need to exit before the package is updated. When the flag was
present, Software Updater would put up the dialog, and if you
confirmed it, send the signal for the app(s) to close.

That way, the dialog would look and behave exactly the same regardless
of which toolkit the app happened to use. And if there was more than
app in that condition, there would be a single dialog listing them,
instead of a separate dialog for each app.

Having said that, neither of the most obvious candidates for
XB-Restart-Required have implemented it, which may not be a good sign
for the efficacy of any future flag.
<https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1104290>
<https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1104289>

This topic was previously discussed in 2009 and 2011, to little avail.
<https://wiki.ubuntu.com/UpgradingRunningPrograms>
<https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-mozilla-upgrade-experience>

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlN59cUACgkQ6PUxNfU6ecorHACaA/D6HSYushOF5b8ME6wK5mNN
NRUAoICFeyRVC5IVEu/2Ja2aiZkPXEhR
=2NBA
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: errors.ubuntu.com and upgrade crashes

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bjoern Michaelsen wrote on 18/05/14 17:17:
> 
> On Fri, May 16, 2014 at 03:21:36PM +0100, Matthew Paul Thomas
> wrote: ...
>> 
>> Frequency is an absolute count. (Perhaps we should call it
>> "Count" instead?)
> 
> thanks for filing the bug. I should have done that myself. My only 
> lame excuse for not doing that is, given the other behaviour I saw,
> I wasnt sure if I possibly completely misinterpreted the thing. As
> for relabeling from frequency to count, Id support that, its a lot
> less confusing.

Done.
<https://code.launchpad.net/~mpt/errors/1320846-frequency-label/+merge/220017>

> ...
> 
>> On the contrary, it seems highly unlikely that anyone would
>> write "crash while installing a font" in a bug report if the
>> button they'd actually clicked was labelled "Start Upgrade".
> 
> The scenario I assumed would be more tricky: its not click "start 
> Upgrade" -> instant crash, rather click "start Upgrade" -> this
> dooms the running LibreOffice instance, but doesnt crash it
> immediately -> LibreOffice crashes way later on without any obvious
> trigger.

Fair enough. More conclusive then is Brian's finding that many of the
occurrences were on fresh installs.

> ...
> 
> Speaking of Launchpad bugs: I dont know of any way to search in 
> errors.ubuntu.com for an Launchpad bug. I just checked the the Top
> 20 stacktraces happening on LibreOffice and all but 4 never
> happened on the version currently in trusty-updates. I would love
> to close bugs not happening anymore, esp. if they a/ happened 
> regulary/statistically significant in earlier versions b/ have no 
> good reproduction scenario.

The table greys out those errors that have not been reported in the
latest package version. Conversely, you can change "all installed
versions" to just the most recent version, to list just those four
errors you're referring to.

Be careful, though: neither of those is definitive if the latest
package version is very new. Maybe a problem still exists, but not
enough people have updated to the latest version, and spent enough
time using it, for anyone to encounter the problem in that version yet.

>> Then the Daisy Pluckers is the team for you. 
>> <https://launchpad.net/~daisy-pluckers>
> 
> I have to trust you on that one, the team description isnt too 
> enlightening. ;)
> 
> ...

Fixed. :-)

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlN5/xEACgkQ6PUxNfU6ecrOqACgmKwf6y7C/yF08X9yeU6N/PqH
KksAn2VtZlYBWcRMza+2YVYob6go2D4i
=a2AM
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: errors.ubuntu.com and upgrade crashes

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthew Paul Thomas wrote on 16/05/14 15:21:
> ...
> 
>> - people use their machines more on weekdays
> 
> Less, actually. <http://launchpad.net/bugs/1046269>
> 
> ...

Sorry, I was confused. It is more on weekdays, not less.

(I was confused because back in 2012, the chart used to show the
opposite. We never figured out why it flipped.)

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlN2IbAACgkQ6PUxNfU6ecqx7ACbBwHup9i8pNObYDvBR36KCkR6
YnUAn0go8Y4o8KCBw9qffo7zWBsi7qZZ
=yxUD
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: errors.ubuntu.com and upgrade crashes

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Seth Arnold wrote on 13/05/14 20:03:
> ...
> 
> At some point Firefox added a handy dialog box to alert running 
> instances that it has been upgraded and should be restarted to run 
> safely.

Which Ubuntu then muddled by illustrating it with a small version of
the Reload icon. 

> The person using Firefox simply clicks "restart" and six seconds 
> later is back where he or she left off and the system runs
> reliably again.
> 
> Perhaps LibreOffice could adopt this mechanism; if it is not
> prepared to be updated while running, it could be adjusted to
> inotify a sentinal file to know to display a "please restart"
> dialog and button to avoid awkward interactions and crashes.
> 
> ...

Mozilla has the resources to include this function. Perhaps the
LibreOffice team does too. But it's neither reasonable nor elegant to
expect every app to do it.

Even if they did, the UI should answer the question: "Or else what?"
If the situation was as you describe, so that the dialog would need to
say "LibreOffice might crash unless you restart it", it would be
mockingly obvious that not restarting shouldn't even be an option.

Anyway, the particular bug Bjoern cited apparently involved
LibreOffice crashing when a font is installed, not necessarily when
LibreOffice is updated. That both of those things often happen during
an Ubuntu upgrade is a coincidence. Requiring LibreOffice to be
restarted when it is updated might be a good idea in general, but it
wouldn't have solved this problem.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlN13JUACgkQ6PUxNfU6eco04QCfSHhqnLzZzgzJ5rvZmZlC17md
lWAAoIvM27lKVSdKyREGzJ6X+nbAzpqJ
=rQEb
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: errors.ubuntu.com and upgrade crashes

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bjoern Michaelsen wrote on 14/05/14 01:47:
> ...
> 
> On Tue, May 13, 2014 at 10:24:20AM +0100, Matthew Paul Thomas 
> wrote:
>> 
>> You can. Set "Most common of these errors from" to "the date 
>> range", then enter the dates, for example 2013-10-16 to 
>> 2013-10-20. The result is not as you remember: over that period, 
>> bug 1219245 was not in the top 50 at all, whereas it was #42 for 
>> the equivalent period around the 14.04 release.
> 
> I tried that, just for fun with the range 2014-04-13 2014-04-19 and
> got:
> 
> libreoffice-core all 25
> 
> libreoffice-core 14.04  120

Oh dear. I've reported that as a bug. <http://launchpad.net/bugs/1320174>

> and went back from 14.04 to all and got a "the list of most common 
> errors could not be loaded" -- from that it is a/ obvious, that the
> numbers are not absolute, but normalized in a way[1] that is making
> them uncomparable

Frequency is an absolute count. (Perhaps we should call it "Count"
instead?) If it was being normalized in any way, it would often be
fractional, but it never is. It seems far more likely to me that it's
a simple algorithm bug, for example forgetting to include 14.04 and
Utopic in "all".

> b/ these errors use to happen always to me after two or three 
> changes to the selection in general, TBH thus made me mistrust
> this data for all but the most basic searches as I am always unsure
> if I see real data or old data with some stalled JSON request.

That's a shame. The database server is unreliable, but I don't
remember a case where it failed *and* the Web site didn't communicate
this with an error message. When it does give an error, you can
usually work around it by changing one of the search parameters and
then changing it back.

> ...
>> 
>> "Supported" is a weasel word. I've never understood why Ubuntu 
>> lets people have apps running during an upgrade, because that
>> has many weird effects. But Ubuntu *does* let people do that. And
>> as long as it does, Ubuntu developers are responsible for the 
>> resulting errors.
> 
> This is hardly a LibreOffice issue -- any interactive application 
> will have such issues, esp. if it has any kind of state. Thus the 
> solution would be for the updater to search and warn about closing 
> such applications.

Sure. And if the Software Updater developers think otherwise, you
should get in a room together until you agree on a solution. Don't
just shrug and blame each other from a distance. :-)

>>> While those upgrade issues should be a concern too, as-is it 
>>> seems to me they are overblown in their importance and we dont 
>>> have a good way to look if they happen in regular production 
>>> use after upgrade.
>> 
>> With respect, I don't see that you have any justification in 
>> deciding that this particular issue is "overblown". A crash in 
>> LibreOffice is just as bad whether it happens during an upgrade, 
>> during a full moon, or during the Olympic Games.
> 
> All bugs are created equal? Not quite, as on errors.ubuntu.com we 
> are ranking them esp. based on "frequency" -- with the implicit 
> assumption that a high frequency bug will keep its high frequency 
> throughout the lifecycle of the release. 'Upgrade-only bugs' break 
> this assumption.

There is no such assumption.

If an error is more common during installation or upgrade than
otherwise, then the only way to judge its overall frequency fairly
would be to average its frequency over the lifetime of an
installation, however many months or years that is. That might be
interesting, but it would be too slow to make any judgements worth
acting on.

Fortunately, we have no evidence that that's any more than a
prioritization problem for the engineers responsible for Ubiquity,
Software Updater, do-release-upgrade and so on. And specifically, we
have no evidence that it's a problem for you.

Maybe LibreOffice does have upgrade-only bugs. But there is nothing in
your example bug report, the corresponding error report, or even the
commit that fixed the bug upstream in February, suggesting that it is
upgrade-only. On the contrary, it seems highly unlikely that anyone
would write "crash while installing a font" in a bug report if the
button they'd actually clicked was labelled "Start Upgrade".

> ...
> 
>> Unfortunately, this calculation goes to hell on release day. All 
>> of a sudden there are a gazillion new machines with the new 
>> version of Ubuntu on them. And of those, some fraction will 
>> report their first error. But that fraction are the only o

Re: errors.ubuntu.com and upgrade crashes

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bjoern Michaelsen wrote on 12/05/14 12:44:
> ...
> 
> while chasing around bug 1219245 as it showed up so high in 
> errors.ubuntu.com I found that:
> 
> - that bug exists since at least LibreOffice 4.0.2 (released with 
> Ubuntu 13.04)
> 
> - all of todays reports come from 14.04 exclusively
> 
> - the bug wasnt ranked high in errors before 14.04 release
> 
> I vaguely remember seeing that bug peaking up on errors right after
> 13.10 was released, just to quickly vanish into irrelevance again
> (I might be wrong there, as I cant go back in time on errors.u.c).

You can. Set "Most common of these errors from" to "the date range",
then enter the dates, for example 2013-10-16 to 2013-10-20. The result
is not as you remember: over that period, bug 1219245 was not in the
top 50 at all, whereas it was #42 for the equivalent period around the
14.04 release.

(Unfortunately I can't link you directly to those results, because of
a bug in the error tracker.  So you
need to enter the dates yourself.)

> While there is no good reproduction scenario in the bug reports, 
> there is one report claiming it crahed "while installing a font" 
> and another it crashed "during an upgrade". This leaves me with the
> suspicion, that the crash is actually people leaving LibreOffice
> running during a release upgrade (which is brave and a nice vote of
> confidence, but not really a supported scenario).

"Supported" is a weasel word. I've never understood why Ubuntu lets
people have apps running during an upgrade, because that has many
weird effects. But Ubuntu *does* let people do that. And as long as it
does, Ubuntu developers are responsible for the resulting errors.

> By extension, this leaves me with the suspicion that the nice 
> exponential drop-off of crash reports for a distro over time is not
> actually us fixing stuff via SRUs (which is way to slow for that),
> but that it is just fewer people doing upgrades vs. people running
> it in production  and experiencing some transitional crashes (that
> do not happen after they use the system 'in production'
> afterwards).

If true, that would be a terrible indictment of our upgrade process!
Fortunately it is not. The spike and drop-off in apparent error rate,
over the 90 days after an Ubuntu release, is a flaw in the error
tracker's calculation.

The true error rate per machine, for any period, is the number of
errors reported overall, divided by the number of machines running
Ubuntu that would report errors if they had any.

The problem is that we don't know the latter. We don't get pings from
machines saying "I'm running Ubuntu, and I would report errors if I
had any, but I didn't have any today". We know a machine exists today
only if it *did* report any errors today.

So we use an approximation for the total number of machines that would
report errors today if they had any: the number of machines that have
reported any errors in the past 90 days. That incorrectly excludes
machines that would have reported errors but fortuitously had zero in
the past 90 days. And it incorrectly includes machines that reported
an error 89 days ago and were then thrown into the garbage. Hopefully
those biases roughly cancel each other out.

Unfortunately, this calculation goes to hell on release day. All of a
sudden there are a gazillion new machines with the new version of
Ubuntu on them. And of those, some fraction will report their first
error. But that fraction are the only ones we know exist at all. So the
denominator is much too low -- making the calculated error rate much
too high.

This is why the calculated error rate for every new release spikes on
release day, and corrects itself over the next 90 days. It's also why
the calculated error rate for 13.10 plummeted at the 14.04 release:
lots of 13.10 machines were upgraded to 14.04, and so from the error
tracker's point of view they're still 13.10 machines that suddenly
became error-free.

If anyone would like to fix this, it's just a simple matter of
programming. ;-) 

> Does errors.ubuntu.com have a way to identify crashers during a 
> release upgrade (or maybe even: first-starts after a release 
> update)? Would it be possible to filter crash reports for that 
> scenario, e.g. trivially: mark crashers 48hours after the upgrade 
> as 'potentially an upgrade sideeffect' or somesuch?
> 
> ...

Probably not retroactively. But I imagine it would be fairly easy to
add info to future error reports asking if do-release-upgrade (or
whatever) was running at the time.

> While those upgrade issues should be a concern too, as-is it seems 
> to me they are overblown in their importance and we dont have a 
> good way to look if they happen in regular production use after 
> upgrade.
> 
> ...

With respect, I don't see that you have any justification in deciding
that this particular issue is "overblown". A crash in LibreOffice is

Re: [Ubuntu-phone] Policy: filing bugs against Ubuntu packages instead of upstream projects

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Barry Warsaw wrote on 26/11/13 15:03:
> 
> On Nov 26, 2013, at 08:56 PM, Thomi Richards wrote:
>> 
>> ...
>> 
>> I suspect one of the issues is that it's easy to miss bugs filed 
>> against the Ubuntu package only. Is there an easy tweak we can 
>> make to launchpad so these bugs are more visible? Or perhaps 
>> there's already a way, but I just don't know about it?
> 
> (Ultimately, it's too bad Launchpad doesn't allow projects to opt 
> into some kind of automatic promotion of bugs from Ubuntu to 
> upstream.)
> 
> ...



- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKV+jkACgkQ6PUxNfU6ecoelQCeMhaeEYRz9DtHrpjd7L6hjSJA
UxAAoLU90CBF6NEOWiz9hv1UpBcyv6O9
=LiHY
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: libappindicator inline pixbuf question

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

JT Olds wrote on 10/05/13 08:44:
> ...
> 
> As you may be aware, Gtk provides a commandline tool called 
> gdk-pixbuf-csource, which generates c source from a given asset.
> It's then possible to use gdk_pixbuf_new_from_inline to get a
> straight up GdkPixbuf* and load that into the icon theme using 
> gtk_icon_theme_add_builtin_icon.
> 
> However, once I've done this and added my icon to the icon theme,
> the AppIndicator menu I have in Unity does not show my custom icon.
> I assume this is because the AppIndicator dbus protocol passes the
> icon name and not the actual icon pixbuf data itself, and the
> indicator server loads the icon in its own process space, oblivious
> to my call to gtk_icon_theme_add_builtin_icon?
> 
> ...

I think this is "API needed: pixbuf icon setting
support".

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGTUjIACgkQ6PUxNfU6ecrDagCeNP+hurIZlmI8UAxdHsPJcSVA
pM4AoJaJdpxleyrmEmihqLDXSyWdvYPn
=GZag
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Should we sunset brainstorm.ubuntu.com?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jorge O. Castro wrote on 13/05/13 21:50:
> ...
> 
> b) User interest (as indicated by the voting) is waning.
> 
> c) It seems that developer interest is waning to a point that some 
> developers feel that responding to the ideas isn't an ideal use of 
> time.
> 
> ...

Those two are related. Ideas are cheap, implementation is hard. And
some potential contributors will have been discouraged from helping
with Ubuntu's implementation because they mistakenly thought posting
ideas to Brainstorm was a good place to get started.

So yes, please, let's retire it.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGR7SoACgkQ6PUxNfU6ecqmrQCfR/27zQqn2ACRSTZU0Jsy5aIL
epsAoLGOxzNNT9PeCz6N14KkmuuY7QbX
=Qf/Q
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: App installer design: click packages

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Colin Watson wrote on 08/05/13 11:14:
> ...
> 
> So, at Steve Langasek's request, I've been putting together a
> proof of concept of a low-level app package installer and
> packaging format. Highlights of what it can do so far are:
> 
> ...
> 
> * installs each app to an entirely separate directory
> 
> * entirely declarative: maintainer scripts are forbidden

Do these two entail that an installation/update/removal can be
interrupted at any point without corrupting the system?

This is, as I understand it, a long-standing problem with deb/dpkg. A
PC has a power outage or a kernel panic while a package is installing
or updating, and the packaged software becomes unusable, and possibly
stymies future package operations too.

An interruption like this is much more likely to happen on a phone or
tablet, because it's much more often on battery while you're
installing something.

> ...
> 
> To do, but not in this project:
> 
> * package acquisition

While designing session-installer error messages, I was told that apt
returns localized error messages but not error codes, making it
impractical for a UI wrapper to respond appropriately to different
kinds of error (e.g. providing a "Try Again" button only when trying
again might actually work). Avoiding this in any new system would be
desirable.

> * indexing support and other frontend things (i.e. the app store)

That will affect the package format. For example, each package
providing metadata in multiple languages.

> ...
> 
> Is there anything else people can think of that a system like this 
> needs to consider?
> 
> ...

A system that aims for an order of magnitude more applications, than
Debian or Ubuntu has packages, should not rely on every package having
a unique name. For example, a package should not determine the name of
the installation directory itself.

Finally (and most bikesheddingly), a system initially aimed at phones
and tablets should not be named after something you do with a mouse.

Cheers
- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGMz9EACgkQ6PUxNfU6ecpWFgCfV9GhyHH95qe/1rZtWCJaNJ/6
3vUAnAzDJiALnaK1bRg525P0yyoomoQS
=vMfc
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: reflecting on first UDS session on "rolling releases"

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bryce Harrington wrote on 06/03/13 15:45:
> ...
> 
> He means not just the core OS but also the application ecosystem.
> In Windows the OS release is just the core OS, and then users
> manually install newer versions of whatever applications they
> want.

As they do in Ubuntu, unless the application is in the core OS
repositories.

> (I would argue that any software project that has their act
> together will have .debs for the LTS downloadable from their web
> site or a PPA, or even via -backports, so in practice this isn't
> that different. However, I believe that was the distinction he was
> drawing.)
> 
> ...

Any software project that has their act together is in MyApps. ;-)

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlE4dhcACgkQ6PUxNfU6ecoZnwCfaK4xj5d8n7sZ7u+KT9Q9/9yi
9GwAn0ueCf6QxkzDj0nY7alflh4DFY+H
=VcaU
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: reflecting on first UDS session on "rolling releases"

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Hall wrote on 06/03/13 00:41:
> 
> On 03/05/2013 06:49 PM, Allison Randal wrote:
>> 
>> There were a few things that concerned me in today's session on 
>> cadence of rolling releases:
>> 
>> http://summit.ubuntu.com/uds-1303/meeting/21683/community-1303-rolling-release/
>>
>>
>> 
But, the biggest was at the very end when System76 said that two
>> years is too long between releases for their customers, but that
>> they were willing to at least *try* the new rolling releases. The
>> reply was that the rolling releases weren't expected to be stable
>> enough to deliver to customers. This surprised me, since
>> "stability" is exactly the purpose of rolling releases.

This was the argument System76's Carl Richell gave against two-yearly
releases: "I don't think Windows or OS X or Chrome OS are going to
release in such a long time. And I'd also look at 11.04, for instance.
If we installed 11.04 on our computers, and used it for a week, is
that how we would want Ubuntu represented commercially? Because that
would be the result of a two-year release cycle."


I don't understand the first part of that argument. Windows 7 and 8
were, actually, both released two years after the previous version. OS
X had 18-to-24-month releases for over a decade, switching to yearly
releases only with 10.7 and 10.8. And Chrome OS has little UI or APIs
of its own, so (I assume) it has less difficulty in keeping "stable"
in any sense of the word.

The second part of the argument is that if 11.04 had been an LTS, with
the new model it would still be the latest Ubuntu release today, and
11.04 was awful. But that is unfair. 11.04 was awful precisely because
we (well, not me, but others;-) thought it was important to land Unity
as early as possible to prepare it for 12.04 LTS a year later. If we
had been doing two-yearly releases only, it would not, I hope, have
landed in that state.

>> If the "rolling releases" really aren't intended for end-users,
>> then we should just drop the fiction, say the change is from a
>> 6-month cadence to a 2-year cadence, and be done with it.

There are three parts to Rick's proposal:
1.  dropping non-LTS releases
2.  making the development version a "rolling release" stable enough
for enthusiast use
3.  introducing monthly snapshots.

But any one of those could be done without doing the others. I have
seen no argument that any of them would depend on either of the others.

> ...
> 
> I think different segments of the community have different ideas
> of what "stable" means:
> 
> Distro devs & power users: "stable" == "things don't break"

Possibly more precisely: "crashes and other errors don't happen".

> App devs, OEMS, NTEU: "stable" == "things don't change"
> 
> ...

Each of those are different, too.

App developers: "stable" == "APIs don't change".

OEMs: "stable" == "hardware compatibility doesn't break".

Non-technical end users: "stable" == "buttons don't move around".

Naturally there is some overlap in what those groups care about. And
there is some overlap in how we control those different types of
stability. But as with the word "support", the word "stable" has just
too many meanings in software discussions to be useful without a
modifier. It's not hard to be precise: use terms like "reliable",
"API-stable", "compatible", and "familiar".

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlE3UIcACgkQ6PUxNfU6ecoTvQCgi38Z7I2j79CfIAvdOerxPWyM
x6oAoI65nYY6s4S2xy59ARXcrVXkDue3
=/VrT
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Hall wrote on 03/03/13 15:48:
> ...
> 
> Does Zynga have to provide a different version of their games for 
> each different version of Android they support, or does Android 
> give them backwards-compatibility so that they can target 2.2 but 
> still run on 4.2?  I'm not an android developer, but I would
> assume it's the latter.  We could only do the same if we could
> ensure that the APIs available in an LTS would continue to be
> available in the following rolling release (at least up until the
> next LTS).

Right. And we couldn't practically do that, for the reasons I gave.
Google controls all of Android's APIs, in a way that nobody does for
Ubuntu. They have engineering resources to maintain backward
compatibility, in a way that nobody does for Ubuntu. And they have
writers to document all those API versions, in a way that we don't
manage for Ubuntu (though you do great work for a small subset).

What we might be able to do, though, is to freeze APIs sometime before
release. That would be more tractable than documenting -- or even
knowing about! -- changes to individual APIs.

In other words, along with UI Freeze, Kernel Freeze, and so on, we
could have an API Freeze. This might be three months, or six months,
or nine months before the release.

> ...
> 
>> So to provide a stable target for ISVs, it is vital that end 
>> users stick to the LTS.
> 
> Again I agree, but I don't think this was the original intention of
> moving to a rolling release.

Rick wrote, "I would expect the stock download page to *only* point to
the last LTS". We would need to make sure that other Web sites, the
app submission process, and so on align with this.

> Would this transition be considered successful if 90% of our 
> current 6-month release users switched to LTS rather than rolling?

Of PCs running Ubuntu 12.04 or later, currently 0.5 percent of them
are running the development version.

If the rolling release goes ahead and we end up with more than 5
percent using the development version, I think we'll have messed up. A
large chunk of Ubuntu's user base would no longer be using a
*platform*, in the sense of something upon which third-party software
and services can practically be provided.

> Because we still haven't solved the problem of getting newer apps 
> into older releases in an efficient manner.

True, but that doesn't mean it's solved -- or even solvable -- for the
development release! (All love and respect to Debian and the MOTUs,
but joining either of them isn't even meant to be "an efficient manner".)

Having LTSes as the only target releases wouldn't fix that problem.
But it would help, in two ways.

First, there would be many fewer versions to target. In the absence of
better evidence, let's say that "being issued with updates" is a
decent proxy for "in active use". (Because if they aren't, why
bother?) With the current model, three years from today, *five*
versions would be being provided with updates: 12.04 LTS (until April
2016), 14.04 LTS (until April 2018), 14.10 (until April 2016), 15.04
(until October 2016), and 15.10 (until April 2017). With the
LTS+rolling model, only *two* versions would: 12.04 and 14. Much better.

(That in itself is a strong reason to switch to this new model. Does
any Ubuntu developer think it would be a good idea to be issuing
updates for five OS versions at once? Even Microsoft doesn't try to do
that.)

And second, in some of the time saved by releasing less often, ;-)
Ubuntu developers could work on other parts of the problem. Making
packaging easier. Documenting the APIs they produce. Maintaining
compatibility for their own APIs for longer. And improving the upgrade
process, so that people upgrade to the next stable release faster and
more often, further reducing fragmentation.


- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEzxHUACgkQ6PUxNfU6ecrCmQCfZnWKKd+OQvO624CpBCpkodXd
s9oAoMjbENWhcrzg+6WGADKTdqRmPpdK
=iKh3
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Colin Watson wrote on 03/03/13 18:28:
> 
> On Sun, Mar 03, 2013 at 10:48:21AM -0500, Michael Hall wrote:
>> 
>> I agree, it was one thing when we would keep the same version of 
>> a library for 6 months at a time, but with a rolling release you 
>> could have one library or another being upgraded to a new major 
>> version every week. So unless those upstreams committed to 
>> backwards-compatibility, all of the work for providing that would
>> fall to us.
> 
> Let's be clear about our thinking on this or we won't get anywhere.
> The problem is not libraries being upgraded to a new major version.
> The problem is the older version no longer being provided.
> 
> ...

This is getting a bit far from my area of expertise, but as I
understand it, only one of the three examples I cited originally could
have been solved by providing two library versions alongside each other.

Here are the references:

Matthew Paul Thomas wrote on 28/02/13 20:14:
> ...
> 
> During the Ubuntu 12.10 development cycle, the messaging menu API 
> changed for architectural reasons. Every application using it 
> broke, but that wasn't so bad -- because end users weren't using 
> it, OS developers expect things to break, and most of those 
> applications were fixed before the 12.10 release.

"FFE: libmessaging-menu transitions for quantal"
<http://launchpad.net/bugs/1040259>

An example of a third-party app failing to cope: "Needs updating on
Ubuntu 12.10 : change in libmessaging-menu api"
<http://trac-plugins.gajim.org/ticket/14>

> But if that change had happened during a rolling release used by 
> end users, either end users would have experienced the breakage,
> or we would have had to pay the cost of reimplementing the old API 
> alongside the new one. That would be a cost our competitors do not 
> pay -- or pay only because they benefit from vastly more and older 
> third-party applications than we do.
> 
> That is not an isolated case. There have been similar API changes 
> for application indicator menus,

This one was, and is, addressed by shipping multiple libraries.
<http://packages.ubuntu.com/search?keywords=libappindicator1>
<http://packages.ubuntu.com/search?keywords=libappindicator3>

(Though I'm told that if you're new to Ubuntu development and you "from
gi.repository import AppIndicator", you get the wrong one. Yay.)

> for Unity lenses and scopes,

January 2012: "Now, as some have picked up, the Unity Lenses API has
changed slightly in Unity-5.0 (the version that'll be in Ubuntu
12.04). First of all; sorry!" <http://www.grillbar.org/wordpress/?p=585>

> and probably for subsystems I've never even heard of. With an 
> end-user rolling release, if you installed OS updates overnight,
> an application you had paid money for could stop working while you 
> slept.
> 
> ...

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEzxEoACgkQ6PUxNfU6ecosKwCeK705CUB9dy3MAU39EW+AaNT3
OpYAnRqmEVoXDwcPRKYvzANDRTKfcyno
=r6LZ
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Hall wrote on 01/03/13 16:21:
> 
> On 03/01/2013 12:34 AM, Martin Pitt wrote:
>> 
>> Michael Hall [2013-02-28 22:04 -0500]:
> ...
>> 
>>> Personally I don't think "target only LTS releases" is going to
>>> be acceptable to most ISVs, especially those writing consumer
>>> "apps", where you can go from nobody to the most downloaded and
>>> back to nobody in the span of 2 years (think of the rapid rise
>>> and fall of games like Words with Friends, or Draw Something).
>> 
>> How is that related to the platform they target? If anything, it 
>> seems to me that targetting LTS only is going to make things
>> easier for this kind of "ephemeral app" use case, as it
>> significantly reduces the required maintenance and porting of
>> those?

Exactly. The minimum OS requirement for even the latest version of
Words With Friends is a two-year-old version of iOS (4.3), or a
*three*-year-old version of Android (2.1). And similar for Draw
Something (4.3 and 2.2).

One can only conclude that if Zynga ported their games to Ubuntu,
they'd be quite happy with 90%+ of users using a nearly-two-year-old
version.

> It depends on who is using the LTS and who is using the rolling 
> release. If a significant number of our users are on the rolling 
> release, or if an important demographic (say, technology leaders,
> or people willing to pay for the latest and greatest) are on the
> rolling release, then ISVs are going to want to target that.
> 
> ...

That is impractical for several reasons. Ubuntu developers don't
control most of Ubuntu's APIs. Even for those we do, maintaining (or,
in some cases, reimplementing) old APIs alongside new ones would
multiply Ubuntu developer effort. And as you know, we barely even have
time to document the APIs in stable releases now,


 let alone being able to say
"use this API if targeting the rolling release from October 4th to
February 21st, and this other API for later dailies".

So to provide a stable target for ISVs, it is vital that end users
stick to the LTS.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEzW6kACgkQ6PUxNfU6ecr9OgCfXZNHeJpRAMtLP2KPABtjbOyj
yB4An26Me/6MSX/Qg2ODH2WN3ksbwpVq
=2uXy
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Langasek wrote on 01/03/13 21:21:
> 
> On Fri, Mar 01, 2013 at 10:55:14AM +, Matthew Paul Thomas
> wrote: ...
> 
>> As I understand the purpose of monthly snapshots so far, we
>> could achieve the same effect simply by adding a "Display
>> monthly" item to that second menu.
> 
> "Display monthly" wouldn't guarantee that users who update monthly
> are updating to the *same* set of monthly packages.  Displaying the
> prompt monthly, even if the user consistently acted on it as soon
> as they saw it, would cause inevitable drift over time;

Not only drift, but they wouldn't even be starting on the same day of
the month. (They'd be starting whenever an admin first connected to
the Internet after installation.)

> we would therefore not be able to provide security support for
> these users, because the security pocket would be updated with
> packages built for the previous monthly snapshot and the user has
> (for example) monthly + 5 days installed.
> 
> ...

There would be no "previous monthly snapshot". I'm proposing a monthly
option for prompting about non-security updates, *instead of* monthly
snapshots.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEzTvQACgkQ6PUxNfU6ecqlRQCfQg3sKbTtxMJ0C5Gs4HV/7r9j
mkEAnj6uh58tX90vU0siJq9Duao8sltc
=T2tq
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Langasek wrote on 01/03/13 21:17:
> 
> On Fri, Mar 01, 2013 at 05:40:26PM +, Colin Watson wrote:
>> 
 The monthly snapshots would be for users who want the fresh 
 software, but don't want to manage the daily grind of
 updating to ensure that their system is secure. The way I
 think of it is that we "support" 2 cadences for updates,
 daily and monthly.
>>> 
>>> As above, that seems like something we'd want to discourage.
>>> Even so, it is already possible in R, without snapshots. It
>>> takes two clicks:
>>> 
>>> 1. When Software Updater appears, expand "Details of updates".
>>> 
>>> 2. Uncheck the checkbox next to "Other updates", leaving
>>> "Security updates" checked. (These groupings appear only if any
>>> of the updates are security updates.)
>> 
>> This is a good point.  (It has no real-world testing, because we
>> have never had a release where we applied changes both in the
>> release pocket and in -security; we have only had releases where
>> we applied changes only in the release pocket, and releases where
>> we applied changes in both -security and -updates.  That said, I
>> agree that this argument holds up theoretically, and thus we
>> could do this without the complexity of staging everything in
>> -updates.)
> 
> Two clicks sounds simple, but it wouldn't be very obvious to users
> who are meaning to track the monthly that they should be
> un-selecting "other updates".  Is there a good way for us to
> pre-unselect this for users who are opting in to the monthly
> updates?

Again, I am proposing this *instead of* monthly snapshots. There would
be no "track the monthly".

In which case, it would be one more checkbox in the Updates settings,
below "When there are other updates". "When displaying security
updates, select other updates too", or something like that.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEzYToACgkQ6PUxNfU6ecq1zwCgnd0tx5Tv28KBe38XrzddWfuE
p5UAn3LQI+PwNNzXT4vgRpGh+/9rGL3R
=COUl
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Let's Discuss Interim Releases (and a Rolling Release)

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jonathan Riddell wrote on 28/02/13 16:49:
> 
> Along with no UDS this feels like a further move away from being a 
> community project for Ubuntu.
> 
> After much time lobbying KDE (and other upstreams) to move to 6 
> monthly releases that has been working nicely for some years but if
> we lose that cadance we will be in danger of losing a lot of what
> makes this work well.
> 
> ...

A six-monthly cadence may have been good compared with what KDE was
doing previously, I don't know. But that does not mean it is the best
approach in general.

The idea of synchronized cadences dates from the days when it was
assumed that a "distribution" was a scalable way to provide all the
software that millions of people would want to use -- from the kernel
all the way up to the Kairo game. That turned out not to be true.

And even if it had been true, the optimal release cycle for a game, a
magazine app, a Web browser trying to push the standards envelope, a
Twitter client trying to stay ahead of API changes, an office suite
aiming for compatibility with a recent proprietary office suite, a
utility for controlling a recently-released hardware device, and a
base operating system, are all likely to be different. Why would
anyone expect them to be the same? Especially on a mobile platform
where many apps are intended for brief lifetimes, such as an
exhibition, conference, festival, sporting event, or magazine issue.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEwoPwACgkQ6PUxNfU6ecoupgCdHK2TZHnac/wtf6VpRiVqjwNK
B0UAn14dprWJ9fDNNM7mgyDRSnTje0Cj
=ih/s
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Langasek wrote on 01/03/13 01:44:
> 
> On Thu, Feb 28, 2013 at 02:05:35PM -0800, Alex Chiang wrote: ...
> 
>> If you want to avoid the daily grind, press the close button
>> when update-manager fires. Or set the 'check for updates'
>> frequency to monthly. I think the intended audience for monthly
>> images could handle that workflow.
> 
> Except we really, really don't want users doing that.  When 
> update-manager fires because there's a critical security update,
> and failing to apply it means their machine will in short order
> become part of a botnet with the best-designed UI the world has
> ever seen, we really don't want the user's first instinct to be to
> postpone the update.
> 
> ...

Certainly we don't want people to instinctively dismiss the dialog.
The recent redesign has aimed at getting consent more often.

But changing the updates frequency instead is a valid option, because
Software Sources has two update frequency settings.


"When there are security updates:", defaulting to "Display immediately".

And "When there are other updates:", defaulting to "Display weekly".

You can change the latter right now to "Display every two weeks",
without delaying your exposure to security updates at all.

As I understand the purpose of monthly snapshots so far, we could
achieve the same effect simply by adding a "Display monthly" item to
that second menu.

However, currently when there are security updates, Software Updater
assumes that you will want to install any available non-security
updates at the same time, to minimize interruption. Minimizing
bandwidth use from update churn is not a problem we optimize for at
the moment (except for warning you when you're on mobile broadband).
But we could add a setting for that if necessary.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEwiREACgkQ6PUxNfU6ecq9sQCeMJfFmmq4W8r1T6ihLc0VIzio
1j0Ani8BmblJn8jwPhsfERVmKmY2X0+4
=jeJp
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rick Spencer wrote on 28/02/13 20:41:
> ...
> 
> On Thu, Feb 28, 2013 at 12:14 PM, Matthew Paul Thomas
> 
> ...
>> So, I'm all in favor of having two-yearly releases. But for the 
>> same reasons as six-monthly releases are bad, monthly snapshots 
>> and/or a rolling release would be much worse -- unless we are 
>> careful to communicate that they are for contributors only, not 
>> for end users or ISVs.
> 
> I would put "enthusiasts" in the category of potential users.
> There are people who will set the dial to much fresher software if
> they can, even if it comes with costs and even if they don't
> consider themselves "contributors".

That's a worst-case scenario for Ubuntu as a platform. The type of
users most likely to install applications, not doing so, because
they're using an Ubuntu version that changes too often for ISVs to
bother with.

> ...
>> I don't understand why you are proposing monthly snapshots at 
>> all. Can you elaborate?
> 
> The monthly snapshots would be for users who want the fresh 
> software, but don't want to manage the daily grind of updating to 
> ensure that their system is secure. The way I think of it is that 
> we "support" 2 cadences for updates, daily and monthly.

As above, that seems like something we'd want to discourage. Even so,
it is already possible in R, without snapshots. It takes two clicks:

1. When Software Updater appears, expand "Details of updates".

2. Uncheck the checkbox next to "Other updates", leaving "Security
updates" checked. (These groupings appear only if any of the updates
are security updates.)

You can later install non-security updates weekly, or fortnightly, or
monthly, or whenever you please. We don't need to provide snapshots
for any of those. At most, we'd tweak Software Sources and Software
Updater, to (in effect) automate the unchecking of the checkbox.

Are there other reasons for monthly snapshots, or would that be a
reasonable substitute?

> ...
> 
>> A download page that offers a choice between the LTS and a 
>> rolling release would be exactly as horrid as one that offers the
>> choice between the LTS and a six-monthly release.
> 
> I would expect the stock download page to *only* point to the last 
> LTS.

Excellent.

> ...
> 
> I think that crash reports is a useful and valid measure of 
> robustness, and your measures do point to the fact that Quality is 
> journey, not a destination. We should certainly continue to focus 
> on decreasing crashes, increasing performance, increasing security,
> etc... all the things that make software robust for users.
> 
> ...

Certainly robustness is much more than just crashes, but
errors.ubuntu.com already records more than just crashes. (And yes, we
take that into account when comparing releases.) If there are other
measurable grounds for claiming one release is more robust than
another, then let's measure them.

Cheers
- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEv0lMACgkQ6PUxNfU6ecpjVQCfcAKHwHQgn0khxLheMsqqTF4v
yEsAnirH34kXD579YVqf0ERofBUw9TSG
=jeKK
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The six-monthly Ubuntu release cycle is exciting for Ubuntu fans, KDE
fans, and (lesserly) Gnome fans ... and awful for pretty much everyone
else.

It's awful for first-time users trying to choose a version, for ISVs,
for OEMs and ODMs, for people who write and run training programs, for
Ubuntu-related book authors, publishers, and sellers, for people
providing tech support, and for Ubuntu developers themselves trying to
release features in a finished state. Little wonder that some of those
groups ignore non-LTS releases altogether.

So, I'm all in favor of having two-yearly releases. But for the same
reasons as six-monthly releases are bad, monthly snapshots and/or a
rolling release would be much worse -- unless we are careful to
communicate that they are for contributors only, not for end users or
ISVs.

Rick Spencer wrote on 28/02/13 15:31:
> ...
> 
> = Role of the LTS Releases =
> 
> Many users prefer their OS does not change very often. We have a 
> great system in place for these users. Every 2 years Ubuntu
> release an LTS and users can ride that LTS for the whole support
> period. Since the LTS comes out every 2 years, they can set a 2
> year cadence of updates if they want to stay "up to date" with LTS 
> releases. I think this 2 year cadence works out very well for
> these users. So, this proposal maintains those LTS releases as
> anchors for those users.

LTS-to-LTS upgrades are tested, and documented, much less than they
would be if they were the only type of end-user upgrade. For that
reason alone, having LTS-only releases would be a good thing.

> ...
> 
> * Many community members recommend only LTS releases to new users 
> because of its longevity and stability, but the interim releases 
> cause confusion about what is the “right” version for someone to 
> install.

For evidence of that, you need only look at
. "The latest features", or
"long-term support"? That's a question people can't reasonably be
expected to know the answer to. It's a choice they should not have to
make.

> * As Scott James Remnant pointed out some time ago, the six month 
> cadence causes features to be either rushed, or to have to wait
> for six months to be released (along with other problems). 
> (http://netsplit.com/2011/09/08/new-ubuntu-release-process/)

LTS-only releases would not solve that problem, but they would reduce
the problem by about 75 percent (three releases out of four).

Less time spent on the release process itself would also allow
more time for actual development. But on the other hand, the urge to get
features and other major changes into an LTS would be even more
frantic and rule-bending than it is for every release now. There would
be no post-LTS interim release as a consolation prize, and two years
is a long wait.

> ...
> 
> More clearly, I think we should:
> 
> * Stop making interim releases.
> 
> * Keep doing daily quality and keep improving our daily quality.
> 
> * Take a monthly snapshot of the development release, which we 
> support only until the next snapshot

For software, the word "support" is incurably vague and best avoided.
What do you mean? Security updates? Backports? Tech support from
Canonical? A section on help.ubuntu.com? A listing on
friendly.ubuntu.com? Repackaging of commercial applications in Ubuntu
Software Center?

I don't understand why you are proposing monthly snapshots at all. Can
you elaborate?

> That means users could choose:
> 
> * The LTS release
> 
> * The rolling release updated daily or as frequently as desired
> 
> * The rolling release updated at least monthly

For example, what is the difference between "daily or as frequently as
desired" and "at least monthly"? Why have both?

> = Benefits of Moving to a Rolling Release =
> 
> A rolling release instead of interim releases will benefit users, 
> community members, and developers.
> 
> == For Users ==
> 
> Users who prefer the LTS releases will be unaffected by this 
> change, at least directly. For users who prefer more up to date 
> software, the rolling release will truly provide the latest and 
> greatest software that they are looking for, but without the 6 
> month wait for a new release. Developers won’t be under pressure
> to rush a feature in before the release deadline, so users will be 
> receiving more complete software when they do get updates.

That would leave, unmeliorated, the biggest problem for users: that,
as you said, "the interim releases cause confusion about what is the
'right' version for someone to install".

A download page that offers a choice between the LTS and a rolling
release would be exactly as horrid as one that offers the choice
between the LTS and a six-monthly release.

Instead, I suggest that the rolling release be clearly targeted only
at Ubuntu contributors. At developers, testers, translators, but not
end users. Not shown on the download page, not "supported" in any
sense, and

Re: Error tracker and bugs in libraries

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dmitrijs Ledkovs wrote on 06/12/12 11:52:
> ...
>> https://errors.ubuntu.com/ lists a vlc crash on rank 90. This
>> crash is probably caused by the underlying libproxy library. Can
>> the error tracker track the libproxy versions instead of the
>> vlc-nox versions?
> 
> Currently we cannot bucket / distinguish crashes between the 
> application or the shared library. So it's a known issue, but hard
> to diagnose the underlying problem. It could be the app is not
> using the api correctly / not handling error codes or it could be a
> crashy library.
> 
> ...

There's a bug report about this. 

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDAjIUACgkQ6PUxNfU6ecqPwwCfXvqCuggRggLppLQ0n7+dzrMQ
5mYAoNKLYXiqxbNMNip5KAQF4tp5VQCP
=80vx
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: LP #657275

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Spencer wrote on 15/11/12 18:46:
> ...
> 
> I'm working on LP #657275 (Apport, "ubuntu-bug should save reports 
> offline automatically rather than giving a cryptic error
> message"). What should be the correct behavior?
> 
> If the user chooses to save the report, how should it be handled
> later when a connection to the Internet is established?

Reporting bugs is an interactive process, so I think you would need
some kind of UI listing pending bug reports, so that later on you can
choose when to complete each one.

> I looked at https://wiki.ubuntu.com/ErrorTracker under "Client 
> implementation" and it says that Apport should save the file and a 
> .upload file to /var/crash; However, it appears that whoopsie
> won't open a URL if there is one, so there is no way to edit the
> bug report.

https://wiki.ubuntu.com/ErrorTracker covers the error tracker only. It
does not cover the use of Apport to report bugs.

> Also, should the report simply be saved automatically or should
> the user be prompted first?
> 
> ...

That depends on what the access point would be for that list of
pending bug reports.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCsuj0ACgkQ6PUxNfU6ecolzQCfcSbpAKYZMekNtIvBxNT48HPQ
T7kAnjawsLs4YIFjIB5UL3eSZPoZi0HM
=ZFJn
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [Desktop13.04-Topic] Integrate a Paper Cuts toolbelt into ubuntu-dev-tools

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Wilson wrote on 26/10/12 13:35:
> 
> On 26 October 2012 11:29, Matthew Paul Thomas  <mailto:m...@canonical.com>> wrote:
>> 
>> This is very similar to the "Contributor Console" I designed in
>> June. <https://wiki.ubuntu.com/ContributorConsole>
> 
> Now that looks super sweet! Are there any plans for it or was it
> just a pie-in-the-sky idea you had?
> 
> ...

Neither. I designed it mainly as a replacement for the
launchpad-integration package, which was dropped in 12.10.
<https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-gnome-plans-review>

It also includes UI for opting in to -proposed updates,
<https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-proposed>
<https://wiki.ubuntu.com/SoftwareUpdates#settings> and for opting out
of phased updates.
<https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-phased-updates>

However, no-one has expressed interest in implementing it yet.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCMCn4ACgkQ6PUxNfU6ecoLFgCfTytCJCmvLrJ2ev832T3EIkvJ
wXcAoJdit8EVVZOU06bH3Ud6sRhzvAsy
=42iV
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [Desktop13.04-Topic] Integrate a Paper Cuts toolbelt into ubuntu-dev-tools

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Colin Watson wrote on 25/10/12 10:22:
> 
> On Wed, Oct 24, 2012 at 12:17:02PM -0400, Andrew Starr-Bochicchio
>> 
>> On Wed, Oct 24, 2012 at 8:26 AM, Chris Wilson
>> 
>>> 
>>> On 24 October 2012 13:23, Chris Wilson 
>>> wrote:
 
 In order for the Hundred Paper Cuts project to stay healthy,
 it needs a constant flow of new bugs, several hundred each
 cycle, for people to work on. Making it easier to report
 paper cuts will help keep the reports flowing, and a desktop
 utility bundled with ubuntu-dev-tools could help with this.
 
 A simple graphical tool that provides an interface for
 reporting new paper cuts, with fields customized for paper
 cut bug reports. ubuntu-bug send a lot of information that is
 not necessary for these kinds of problems.
 
 An application picker (I think GTK3 has a pretty good one)
 that will list all the applications installed on the system
 that are covered by the paper cuts project. When the user
 chooses one, relevant data about the version of the app,
 installed plugins, etc, will be added to the report.
> 
> Presumably the user already has the application in question open,
> so it would be simpler to allow them to point to an open window and
> have the reporting program work out the package from that.
> 
> ...

This is very similar to the "Contributor Console" I designed in June.


- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCKZhMACgkQ6PUxNfU6ecop0ACgmczvex/IRQA78Vc4QHq7y7UF
XPsAoIwr9Rc1+CXdbudaelHSuGcgGcsW
=dxIJ
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Simple but worthwhile to fix bugs?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Holbach wrote on 04/09/12 10:47:
> ...
> 
> Another question is: what kind of fixes do we want new contributors
> to work on? How simple is too simple? Are we afraid of typo fixes
> piling up in the queue?
> 
> ...

This is precisely what the "bitesize" tag is for, right?


- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBO8xMACgkQ6PUxNfU6ecoL+QCgnk7J0DZJY97JQgTwgD4srsI7
j8EAn1CXjJQheMncNvy3QZMElnVxT7Hp
=qWcH
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proposing a New App Developer Upload Process

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Scott Kitterman wrote on 06/09/12 22:02:
> 
> On Thursday, September 06, 2012 09:36:05 PM Matthew Paul Thomas 
> wrote:
> 
> ...
>> Scott Kitterman wrote on 06/09/12 14:22:
> ...
>>> To pick just one example, rolling delivery of applications and 
>>> offering multiple versions of the same package (which is what 
>>> the BSD Unixes do, although not in a way I've personally found 
>>> at all satisfying as a user) implies huge changes in package 
>>> management. Not the least of which is the ability to support 
>>> downgrades, including migrating per user settings back to 
>>> previous versions.
>> 
>> Windows, OS X, iOS, and Android all let an author issue a new or 
>> updated application within a week or so of wanting to, which I 
>> guess is what you mean by "rolling delivery". This whole 
>> discussion is predicated on that being a requirement for a 
>> mass-market OS.
> 
> On iOS and Android there's rather more extreme sandboxing than is 
> being proposed here that make potential interactions between 
> applications less of an issue.  The term DLL hell was invented for 
> Windows.  I don't think it's at all obvious that replicating the 
> existing systems is a path to success.

DLL hell or no, Windows and (lesserly) Mac OS were both popular for
decades before they both introduced sandboxing this year. But let's
leave aside the definition of "success".

What kind of sandboxing, specifically, do you think would be necessary
for hundreds of thousands of Ubuntu applications not to interfere with
each other? It seems to me there are four possible points of contention:
1.  package names (versus the OS archive, and versus each other)
2.  installed files
3.  saved documents and settings
4.  resource use (memory, CPU, network, peripherals) while running.

All four might have benefits, but for this particular goal I think
it's sufficient to have technical measures for #1 and #2. Do you at
least agree on that?

> There is an assumption here that there's a vast user base that 
> awaits if only it weren't so hard to run the latest versions of 
> things.

That's a misunderstanding. There are, indeed, users who get annoyed
when they can't play a game like Hedgewars online because the packaged
version of the game is too old for the server. (Raises hand.)

But the main motivation is that one of the things we need for a vast
user base is an order of magnitude more and better applications. And
one of the things we need to attract those application developers is
the ability for them to issue new and updated applications at will.
It's not sufficient, but it is necessary.

> ...
> 
>> None of those OSes offer application downgrades (though 
>> individual applications might). None of them migrate user 
>> settings to previous versions. ("The file “iTunes Library” cannot
>> be read because it was created by a newer version of iTunes.
>> Would you like to download iTunes now?") And absent that settings
>> problem, OS X is the only one that makes multiple application
>> versions moderately easy ("portable apps" on Windows being the
>> exception rather than the rule). That tells me that while they
>> might be desirable, none of those three things is a requirement
>> for a mass-market OS.
> 
> It is also quite normal for things to get screwed up on other 
> operating systems and people do a full reinstall to fix it.  One
> of the fundamental design principles behind package management in 
> Debian and by extension Ubuntu is that once installed, systems can 
> just be upgraded.  Reinstalls should not be needed.  I think this 
> is an important feature that should not be lightly abandoned.  I 
> think the implication of that is you've got to find a way to 
> support downgrades.

It is not an implication of that, because Debian and Ubuntu have never
allowed downgrades. Upgradeability may be a design principle behind
package management in Debian and Ubuntu, but downgradeability is not.

Lack of rollback in general is a big problem: woe betide you if your
battery runs out during an update. But again, that doesn't mean that
problem is best solved together with the app developer upload problem.
If you think it should be, now is the time to explain why.

> I think it's feasible, perhaps using something like etckeeper, but 
> it would take work.
> 
> Allowing areas where we beat the proprietary competition in 
> quality/ capability to degrade to their level is not a recipe for 
> success.

Beat them how? Windows Installer allows rollback to a known-good
state. dpkg does not.

> ...
> 
> The current ARB process and thi

Re: Proposing a New App Developer Upload Process

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Scott Kitterman wrote on 06/09/12 14:22:
> 
> Matthew Paul Thomas  wrote:
> 
> ...
>> Scott Kitterman wrote on 05/09/12 18:54:
> ...
>>> 
>>> - In this brave new world, what is the definition of "Ubuntu 
>>> itself"? If the application developers are unshackled then it 
>>> must be some subset of what we consider Ubuntu to be today.
>> 
>> The shell and everything that makes it work (down to the kernel 
>> and init system), the toolchain, official developer APIs and the 
>> software that implements them, and whichever apps are installed 
>> by default.
> ...
> 
> I suspect not everyone shares your definition of what Ubuntu 
> is/will be.  Even the I favor a more traditional scope myself, I'm 
> very surprised you didn't include the desktop environment (e.g. 
> Unity, Plasma, etc.).

That's what I meant by "the shell".

> I think it's critical that there be some shared vision of where we 
> are going and even though there won't be resources to do
> everything at once, a broad outline of the chunks of work needed to
> get there.
> 
> To pick just one example, rolling delivery of applications and 
> offering multiple versions of the same package (which is what the 
> BSD Unixes do, although not in a way I've personally found at all 
> satisfying as a user) implies huge changes in package management. 
> Not the least of which is the ability to support downgrades, 
> including migrating per user settings back to previous versions.

Windows, OS X, iOS, and Android all let an author issue a new or
updated application within a week or so of wanting to, which I guess
is what you mean by "rolling delivery". This whole discussion is
predicated on that being a requirement for a mass-market OS.

None of those OSes offer application downgrades (though individual
applications might). None of them migrate user settings to previous
versions. ("The file “iTunes Library” cannot be read because it was
created by a newer version of iTunes. Would you like to download
iTunes now?") And absent that settings problem, OS X is the only one
that makes multiple application versions moderately easy ("portable
apps" on Windows being the exception rather than the rule). That tells
me that while they might be desirable, none of those three things is a
requirement for a mass-market OS.

> It doesn't give the user much to give them the ability to choose 
> when to upgrade a package if you don't also give them the ability 
> to change there mind if the experience is poor with the new 
> version.
> 
> ...

Even if that's a problem worth solving, that doesn't necessarily mean
it's best solved at the same time as the app developer upload problem,
or that it even affects the solution for that problem. If you think
either is true, perhaps you could explain why, and describe how the
solutions might coexist.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBJCTUACgkQ6PUxNfU6ecrpjwCfWGsn4/++Veu53znGt4Bh7kFp
PhsAnj+SRqJFv0z6dKqg030KuJ8jEaHF
=7jqA
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proposing a New App Developer Upload Process

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Scott Kitterman wrote on 05/09/12 18:54:
> 
> Matthew Paul Thomas  wrote: ...
>> 
>> That's a near-tautology. "Distributions" are named after the 
>> assumption that selecting and packaging other people's software
>> is a way to produce a useful operating system.
>> 
>> That may work for a few hundred thousand or even a few million 
>> notebook/desktop users, but it has failed to grow beyond that.
>> The distro model discourages application developers, slows
>> application updates (making the installed base less reliable and
>> less secure), and distracts Ubuntu developers from improving
>> Ubuntu itself. Eventually the time comes to say "enough, let's
>> try something else".
> 
> This though is a much bigger step than just providing an easy
> entry point for additional apps.

Sure. It's necessary but not sufficient.

> It brings in many fundamental questions that need to be answered 
> before we can really start to proceed:
> 
> - In this brave new world, what is the definition of "Ubuntu
> itself"? If the application developers are unshackled then it must
> be some subset of what we consider Ubuntu to be today.

The shell and everything that makes it work (down to the kernel and
init system), the toolchain, official developer APIs and the software
that implements them, and whichever apps are installed by default.

> - How do we provide stability for users that are more interested
> in using what they have than the latest upstream crack that was
> pushed out the door at 2am last night?

By presenting application updates as opt-in rather than opt-out.
<https://wiki.ubuntu.com/SoftwareCenter#updates>

> - How do we deal with library transitions?

Others on this list can answer that far better than I can.

> - If application author s are getting unleashed, why can't library 
> authors get unleashed too?

Because those are mutually exclusive (at least for libraries that are
part of Ubuntu itself), and on a successful platform application
authors are far more numerous and distributed.

A library that wasn't part of Ubuntu itself could be unleashed in the
same way, but it would be application authors' responsibility to judge
how serious the library author was about backward compatibility.

> - What about packages that provide both applications and
> libraries?

They would have to play by library rules: preserve backward
compatibility, and/or not be part of the official APIs.

> - What does it mean to be a distribution?

A distribution is to an operating system as a runway is to a flight.
It's the expensive but vital buildup of momentum before takeoff.

> ...
>> 
>> There are a lot of developers involved in packaging, compared to 
>> what? Two years ago there were 160 MOTUs. Today there are 149.
>> That isn't how you scale to an order of magnitude more
>> applications.
> 
> Certainly, but that's also the result of a determined effort to
> kill off MOTU from which that community has never recovered.  There
> is some good work going on now to bring in new blood, so I expect
> the numbers to start to improve.

I'm surprised to read of "a determined effort to kill off MOTU", but
if those numbers increase then good. MOTUs will be vital for years to
come.

> I do agree that we need something different to scale to an order
> of magnitude more applications.  I don't agree that doing that 
> particularly solves any problems we're having.  I can't remember
> the last time I wanted a tool to do a job and there wasn't one
> handy, with the exception of cases where a free software solution
> wasn't legally possible.

That's great, but not particularly telling, because if it wasn't true
perhaps you'd no longer be here to discuss this.

>> Maybe the current proposal isn't the best way to solve the
>> problem. But the first step is to recognize the problem.
> 
> I understand the problem statement.  To the extent there are real 
> problems (e.g. key applications out of date), this proposal is
> barely the tip of the iceberg of what would need to be addressed to
> make the transition to a model where we outsource that to
> application developers.
> 
> ...

So, assume that we can't do everything at once, but we want to act as
soon as possible. What do you suggest we do as well, or instead?

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBIgEMACgkQ6PUxNfU6ecpzrgCfYKFQU8BFj8bqAGZIVcKtalOV
lOIAn2Ravn4zOBwxmDQY9SuxVeQVvzv/
=IY8E
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proposing a New App Developer Upload Process

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Scott Kitterman wrote on 05/09/12 04:39:
> 
> On Tuesday, September 04, 2012 06:01:56 PM Steve Langasek wrote: 
> ...
>> 
>> There's a general sense that the Ubuntu archive can't scale out 
>> to the degree it needs to in order to take on the next challenges
>> for the platform. While Debian packaging isn't hard for you or
>> me, and while it's definitely gotten much easier over the past 4
>> years or so, it's still not so easy that we blindly trust outside
>> contributors to get the packaging right without review by an
>> Ubuntu developer.  We do not have an infinite supply of Ubuntu
>> developers to do this review. Should the set of software
>> available to Ubuntu users through apt be limited to only that
>> software that Ubuntu developers (or Debian maintainers) have time
>> and interest to take care of directly?  Or should users have
>> better (not perfect, but better) ways to install software that's
>> not gotten the attention of the elite inner circle?
> 
> First, this elite inner circle has an open door.

Which requires using Launchpad Bugs (regardless of where you actually
track bugs for your application), knowing what "Debian" is, using the
archaic IRC chat system, signing a "Code of Conduct" that is almost
entirely about contributing to Ubuntu itself, and other things that,
for a typical application author, have no relevance whatsoever.

This inner circle didn't deliberately set out to be elite.

> Second we also have a limited supply of ARB reviewers.  Starting a 
> new review process (ARB) because their aren't enough reviewers was 
> clearly doomed from the start, so much of my "I don't understand 
> this" comes from the current process where we substitute one review
> process with insufficient reviewers for another one with 
> insufficient reviewers.

Yes, I sighed when the ARB was announced for the same reason. But the
conclusion should not be to go back to the first process that still
has insufficient reviewers. It should be to find a process that does
not require reviewers -- or at least, requires them to spend on the
order of a hundredth of the time per application that they do now.

> Additionally, I think the notion that "Oh, X has a bazillion apps, 
> so we need that many too" is mistaken in many regards.  How many 
> office suites do we need? I'd say one that works robustly, 
> reliably, and compatibly with it's proprietary competition (and 
> despite a huge amount of work by people deeply interested in 
> solving this problem, IMO we don't have it). How many solitaire 
> games do we need?  I'm not sure, but I'm confident it's fewer than 
> one finds in whatever Android Marketplace is called now.

Nearly two decades have passed since operating systems were judged
primarily by their office suites and solitaire games. Photo
retouching, online note syncing, genealogy, kiosk-style UI for the
elderly, music notation, home accounting, calendaring, paying taxes,
making greeting cards, chess, Web design, screencasting, CAD, school
timetabling, wedding planning, screenwriting. For thousands of "long
tail" genres like those, competing OSes have multiple applications to
choose from -- but the published choices in Ubuntu are either
non-existent or, not to put too fine a point on it, terrible.

Now, there are many reasons for that: difficulty of publishing is far
from the only one. But it would be a subtle error to think that an
application not existing for Ubuntu at all means that difficulty of
publishing is unimportant. It may be one of the reasons nobody
bothered to develop the application in the first place.

> Historically, Linux distros have included a curated collection, 
> some larger, some smaller, of relevant applications, libraries, etc
> that can be used on the base operating system.  That curation 
> process is one of the real strengths of Linux distributions...

That's a near-tautology. "Distributions" are named after the assumption
that selecting and packaging other people's software is a way to
produce a useful operating system.

That may work for a few hundred thousand or even a few million
notebook/desktop users, but it has failed to grow beyond that. The
distro model discourages application developers, slows application
updates (making the installed base less reliable and less secure), and
distracts Ubuntu developers from improving Ubuntu itself. Eventually
the time comes to say "enough, let's try something else".

> ...
> 
> There are a LOT of Debian/Ubuntu developers and non-developers 
> involved in packaging, so I suspect the good stuff will get 
> attention (I may be wrong).  If such a system existed, then, if it 
> was really clearly distinct from Ubuntu, I think it might make 
> sense, but what's been done so far doesn't meet that goal and 
> neither does what's specified.
> 
> ...

There are a lot of developers involved in packaging, compared to what?
Two years ago there were 160 MOTUs. Today there are 149. That isn't
how you

Re: Ubuntu Release Sprint

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

a.gra...@gmail.com wrote on 20/08/12 09:18:
> ...
> 
> On 20 August 2012 10:38, Matthew Paul Thomas  
> wrote:
> 
> ...
> 
>> On that page, you suggest having one of these sprints in July and
>> one in January.
>> 
>> Why not do it every week?
> 
> because even if we did an Hangout for the half of the blueprints 
> discussed in the previous UDS, it would take at least 4 hours for
> 5 days of the week.

Yes, but even if you were doing it every six months -- and
*especially* if you were doing it every week -- there would be no
point in having a Hangout for even half the blueprints. For most of
them, the only thing to say would be "welp, there's still no-one
working on this". (There are often sessions like this at UDS, for
example on the Common Printing Dialog, or two-factor authentication.)

Instead, have a Hangout only for those features that anyone is
actively working on that week.

> Imagine it like being at UDS:
> 
> ...

No, don't do that. UDS is not a good example of how to get work done.

> ...
>>> Maybe we should schedule a session at next UDS to talk about 
>>> this?
>> 
>> Why wait until then? Why not start now?
> 
> you are right! I was just thinking that maybe organizing this 
> face-to-face would be easier, but why don't we simply schedule 
> an Hangout session soon and discuss about it? It would be the best 
> way to test if it works :)
> 
> ...

So, here's what I suggest:

1.  Choose one of the features you're working on right now.

2.  Mail this list to say "I'm going to start a weekly Hangout about
{feature} next week. If you're interested, reply privately to tell
me how you're involved and which UTC hours you'll be available."

3.  After a few days, choose a time that most suits the people who are
most involved, and follow up to announce it.

Then if it turns out to be a good idea, people working on other
features will start doing the same thing.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAzQxcACgkQ6PUxNfU6ecoRFwCfTeGhJ5WP5/sx9rNAAuQFYBW1
6OgAn0NkrNBDq2F9s9bGsfB+/o8hpNZC
=oSCL
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu Release Sprint

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

a.gra...@gmail.com wrote on 16/08/12 13:53:
> ...
> 
> From an UDS and the next one, it would be useful to have a
> development sprint where people can talk about assigned UDS
> blueprints, at which point they are on their tasks, if they have
> any problems and if they will finish them within the next UDS.

Excellent idea.

> Of course Canonical cannot organize another meeting, it would be
> very expensive, so the idea is: why don't we use Google Hangout to
> organize the sprint? I has a limit of 10 people, I know, but we
> could select (for example) 5 from the community and 5 from
> Canonical. There would be parallel meeting and tracks, we would use
> the same blueprints used during the last UDS and we would add
> further notes. The attendees would be able to listen and watch the
> stream and make questions through the available chat.
> 
> I've also created a wiki page with more informations and you can
> find it here: https://wiki.ubuntu.com/UbuntuReleaseSprint

On that page, you suggest having one of these sprints in July and one
in January.

Why not do it every week?

> What do you think about? I know that Canonical is already
> organizing sprints and this could be a way to involve more the
> Ubuntu Community.
> 
> Maybe we should schedule a session at next UDS to talk about this?
> 
> ...

Why wait until then? Why not start now?

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAx6XMACgkQ6PUxNfU6ecpIygCfTdC9RNr+5SVWFSpEw4FceeCW
Bx4AoNNCXsDt4ggkPsbiaWdU0rtzu4iC
=gqO4
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Overview of Jockey replacement; options for Kubuntu?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mario Limonciello wrote on 04/06/12 21:54:
> ...
> 
> 1) Once there is support directly in software center to indicate
> which packages support your hardware, will Jockey be dropped from
> ubuntu ISOs?
> 
> ...

Ubuntu Software Center already, in Ubuntu 12.04, has the ability to
show you whether a particular package runs on your hardware. But that
has nothing to do with Jockey.

And conversely, the replacement for Jockey has nothing to do with USC.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/XDkoACgkQ6PUxNfU6ecpjhwCgv2bljgunafEHnoDfN9MlFcjP
YOAAnAj1lD/nHaa96yDkgr35bBf1c2BQ
=X9Xs
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Changelog entries for post-release updates

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- - -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Clint Byrum wrote on 01/02/12 04:32:
> ...
> 
> Excerpts from Scott Kitterman's message of Tue Jan 31 19:04:29 
> -0800 ...
>> 
>> ifupdown (0.7~alpha5.1ubuntu5.1) oneiric-proposed; urgency=low
>> 
>> * Cherry pick fixes for label handling from upstream git (LP: 
>> #876829): -
>> http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/100d6f75b985
>>
>> 
- - http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/2d171c8da8e5
>> -
>> http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/f9cef973859e
>>
>> 
- - http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/80a68bbbd45d
>> * Update test suite accordingly.
> ...
> 
> We, the SRU team, should have rejected this changelog, per point 4
>  on https://wiki.ubuntu.com/StableReleaseUpdates
> 
> "Upload the fixed package to release-proposed with the patch in
> the bug report, a detailed and user-readable changelog, and no
> other unrelated changes."
> 
> I have to agree with Scott that this was not user-readable, and 
> perhaps this point should be stressed a bit.


I'm not sure what you mean by "user-readable". If you mean
"understandable by a typical PC owner", then in my seven years using
Ubuntu I have not yet seen a changelog that is user-readable. So
merely stressing the point may not help, ;-) and maybe we should
discuss what would work instead.

Consider the DigiNotar key revocation last year. Here's what the
update changelog looked like in Windows:
|
| Update for Windows 7 (KB2616676)
|
| Install this update to resolve an issue which requires an update to
| the certificate revocation list on Windows systems and to keep your
| systems certificate list up to date. _Details..._

What was good about this? It was written in plain English, and it told
you that the update resolved the problem. What was bad about it? It
didn't actually tell you *what* the problem was, when you might
encounter it, or how dangerous it was. But it did link to a Knowledge
Base article that, in turn, linked to a detailed security bulletin
answering those questions. (If you're prepared to click on enough
links, Microsoft documents their updates up the wazoo.)

Here's how the update changelog appeared in OS X:
|
| Security Update 2011-005
|
| *   Certificate Trust Policy
|
| Available for: Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X
| Lion v10.7.1, Lion Server v10.7.1
|
| Impact: An attacker with a privileged network position may
| intercept user credentials or other sensitive information
|
| Description: Fraudulent certificates were issued by multiple
| certificate authorities operated by DigiNotar. This issue is
| addressed by removing DigiNotar from the list of trusted root
| certificates, from the list of Extended Validation (EV)
| certificate authorities, and by configuring default system trust
| settings so that DigiNotar's certificates, including those issued
| by other authorities, are not trusted.

What was good about this? It was written in plain English. It
explained what the problem was, and how dangerous it was. It even
explained how the fix solved the problem. What was bad about it? Not
much, though it didn't tell you when you might have encountered the
problem (e.g. when visiting a Web site).

Now here's how the equivalent update (or one of them, at least)
appeared in Ubuntu:
|
|  * SECURITY UPDATE: Add patch from Debian version 3.12.11-3 rebased
| against
|3.12.9 to remove the DigiNotar certificates and actively distrust
| them;
|Thanks to Mike Hommey from Debian for the original patch (LP:
| #837557)
|- mozilla/security/nss/lib/ckfw/builtins/certdata.*:
|  Explicitely distrust various DigiNotar CAs:
|  - DigiNotar Root CA
|  - DigiNotar Services 1024 CA
|  - DigiNotar Cyber CA
|  - DigiNotar Cyber CA 2nd
|  - DigiNotar PKIoverheid
|  - DigiNotar PKIoverheid G2
|- mozilla/security/nss/lib/ckfw/builtins/certdata.*:
|  Remove DigiNotar Root CA.
| -- Micah Gersten  Wed, 07 Sep 2011 14:53:13 -0500

What was good about this? It named the developers responsible for the
update, a nice personal touch. What was bad about it? It didn't say
what the problem was, when you might have encountered it, or how
dangerous it was. It was riddled with jargon: "Debian", "rebased",
"nss/lib/ckfw", "certdata". It was written in imperative mood, which
could have been misinterpreted as instructions. ("I'm supposed to add
a patch from Debian version? how do I do that?") It didn't say whether
the update completely resolved the problem. And it misspelled
"Explicitly", making the update seem less trustworthy.

Now, I'm not at all picking on Micah here. This was a completely
typical Ubuntu changelog. Almost every Ubuntu changelog has roughly
the same problems.

How might we fix this?

At UDS Karmic in 2009, the Ubuntu Security Team discussed a new format
for

Wanted: Port of release-upgrader to aptdaemon

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

release-upgrader is the part of Update Manager that upgrades Ubuntu
from one version to the next.

Currently it uses apt directly. This has several drawbacks. For
example, it uses the ugly gksudo prompt instead of the nicer PolicyKit
one. And if you happen to be installing or removing an application in
Ubuntu Software Center, instead of waiting for that to finish, the
upgrade just fails.

These problems can be fixed by porting release-upgrader to use
Aptdaemon, like Ubuntu Software Center and the rest of Update Manager
do. (It would also make sense to split it off into a separate codebase
from update-manager.)

If anyone would like to tackle this, here's the code:


And here's the Aptdaemon reference:


If you need help, you can find Michael Vogt (mvo) in the #ubuntu-devel
IRC channel.

Thanks!

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8iqrcACgkQ6PUxNfU6ecrolwCdHYDbo3UMnVF0SPA4G/H1Os+u
A4gAnjS0X30sOpzLwvtPY4DoRxk8MTcy
=rHX9
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: How to properly communicate on what components versions we will use in a cycle?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sebastien Bacher wrote on 29/11/11 18:44:
> ...
> 
> I'm going to send emails to ubuntu-devel about the versions of 
> webkit and poppler (and maybe some other components as well) the 
> desktop team plans to use, I'm interested to know if: - that list 
> is the right place for those informations and to get feedback on 
> the choices we are taking - those informations are useful for you 
> (do all the derivatives teams read the list?) - we have a standard 
> way to track the choices different teams have taken about
> targetted for the versions (with maybe some reasons on the "why")
> or if we should try to get one? - what components should be
> discussed this way (or another)? I guess each derivatives has a
> list of components they depends on and would welcome to be informed
> and able to give their feedback on the choices we are doing.
> 
> ...


Independent application developers are likely to want to know those
component versions.

For example, someone developing an application that embeds Webkit
would want to know whether, in Ubuntu 12.04, they will be able to rely
on features introduced in a particular Webkit version. And ideally,
they'd want to know this months beforehand.

So if one standard way is set up to document those component versions
for each Ubuntu release, maybe that standard way should be a page on
developer.ubuntu.com.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7Y5zoACgkQ6PUxNfU6ecpcMwCbB/nY7DVVEMhbZTbWity7JfZG
FxEAoJN13wcRMOEN44jWNEMShAvI6Eow
=cNIW
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: User interface defect: Keyboard settings preference pane

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Boyle wrote on 14/10/11 09:43:
> ...
> 
> In the "System Settings" control-panel thing, there is a preference
> pane called "Keyboard".  The Keyboard preference pane has a
> "Typing" tab, which allows the user to set the delay and speed for
> key repeats when a key is held down, as well as to set the blinking
> speed for a cursor in text fields.
> 
> The problem is, this preference pane does not provide a text field 
> to demonstrate the effects of the user's settings.
> 
> ...


This is reported as .

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7CoJIACgkQ6PUxNfU6ecrmCQCg0dB869uTi4Am0NW3zJ7eKVaH
EYYAnj/gNs8dHgw7H0o065/QzF3rvv91
=Z+a1
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Getting new packages into Ubuntu

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stefano Rivera wrote on 10/10/11 20:24:
> 
> Hi Sebastien (2011.10.10_20:34:48_+0200) ...
>>> * No obvious approaches to handling security issues or bug 
>>> reports yet.
>> 
>> How does android or app stores deal with those?


As well as linking to the developer's Web site, which Ubuntu Software
Center already does, they sometimes have another link specifically for
reporting problems. We'd like to add that too.


> ... When you download something from the software centre, the 
> origin isn't obvious. Currently, I think about the only obvious 
> feedback mechanism is the reviews in Software Center (are those 
> visible on the web anywhere?). By doing this, we are also aligning 
> Ubuntu with these apps, to some degree. People find the quality of 
> the apps in smartphones application stores to be a discriminator 
> between smartphone platforms. I think that'll easily carry over to 
> Ubuntu, and people will measure Ubuntu by the quality of the app 
> store.
> 
> We don't want as little responsibility as possible. We want to 
> create the best experience for our users and ourselves.


That isn't a one-dimensional landscape, though. More oversight also
means more time and effort to publish an application, which means
fewer applications, which means a worse experience. (Or,
alternatively, a good experience for fewer people.)

The past 18 years of Debian and Ubuntu have shown that the model of
"we package all your stuff, and people upgrade their OS to get it" is
not a peak on that landscape. Or at least, not one high enough to be
competitive.

>> We shouldn't aim at getting libraries in extras, the libraries 
>> should be part of the platform an in the archive itself then.
> 
> I'm talking about bundled libraries, not library packages.
> There'll be ARB apps that need libraries that aren't in Ubuntu.
> (And probably ARB apps that want different library versions to what
> we ship in Ubuntu).
> 
> ...


Ubuntu developers announce, months in advance, what kernel and
toolchain versions will be used in the next release. Minimizing the
library problem may involve doing something similar for libraries (or
at least library API versions). So if you want your application
published for that Ubuntu version, you can write to that version's APIs.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6UlZ4ACgkQ6PUxNfU6ecpCagCgmTGk1ZgIvSqBLUQkVLerPYLl
zUkAn1YQ2vltlKQyTu8cchWPGr19pMgs
=3mXM
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Crash database requirements

[Matthew Paul Thomas]

Rick Spencer wrote on 11/08/11 11:32:
>

On 08/11/2011 12:02 PM, Matthew Paul Thomas wrote:
...

With my proposed design it's two clicks to submit, then another
click to dismiss the error message. Probably I should simplify it
further.


I've just changed the design to require one click rather than three.
<https://wiki.ubuntu.com/ErrorTracker#Client_design>


Would it not be possible for the user to opt in, and then have the
reports submitted silently in the background on behalf of the user
without bothering them at all?


Ubuntu has always had the problem that if a program with a window 
crashes, the window just disappears with no explanation. The error 
reporting system fixes that too -- but only if it shows up for each crash.


For internal (i.e. thread) errors, it may make sense to give the option 
of sending them in the background. Or it may make sense to aggregate 
them by time, for example no more than two per hour, no more than three 
per Ubuntu session. Or both.


--
mpt

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: project ideas ubuntu

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Gaurav

Gaurav Saxena wrote on 25/09/11 18:08:
> 
> hello all i want to do a my fina; year projrct on ubuntu.. please
> help me with some ideas realted to ubuntu on which i can work...

These mailing lists are for current Ubuntu developers. They are not
really suited for beginners.

I suggest instead contacting a team related to what you are interested
in. 

When you do, mention what subject you are studying, and what kind of
project it is.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6AolQACgkQ6PUxNfU6ecp0zgCgiKXLJzRVKlNfsCIwkzZhmf4J
HOcAnR7C+VEg6V9bhWVLQHzp7nYrfICj
=poW5
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Crash database requirements

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christopher James Halse Rogers wrote on 09/08/11 06:37:
>
> On Mon, 2011-08-08 at 00:34 -0700, Bryce Harrington wrote:
>...
>> Here's a start...
>>
>>  * A collection of files are gathered client-side and inserted into
>>the crash database record.
>>
>>  * Processed versions of files (i.e. retracer output) can be added
>>subsequently.
>>
>>  * Some files must be kept private (i.e. core dumps)
>>
>>  * Traces from multiple crash reports are algorithmically compared to
>>find exact-dupes and likely-dupes.
>>
>>  * Crash reports can be grouped by package, by distro release, or by
>>both.
>>
>>  * Statistics are generated to show number of [exact|exact+likely]
>>dupes for each type of crash.  Statistics can be provided by
>>package, by distro release, by date range, or a combination.
>>
>>  * Bug report(s) can be associated with a given set of crashes.
>>
>>  * The user should have some way to check back on the status of their
>>crash report; e.g. have some report ID they can look at to see
>>statistics and/or any associated bug #.
>>
>>  * The user should have some way to check back on the status of their
>>crash report; e.g. have some report ID they can look at to see
>>statistics and/or any associated bug #.

This one will be tricky without weirding people out ("what is this
'Launchpad' thing and why is it on my computer?"), but I'm sure there's
some way of making it subtle enough.

> To this list I'd add: 
>  * It should be brainlessly easy for users to submit this data.
> Either a single "Yes, submit this crash" confirmation, or a check box
> to automatically submit these crashes.  One of the features that the X
> team really desire out of this sort of database is "how frequent is
> this kind of problem", which requires the widest possible sample
> space.

With my proposed design it's two clicks to submit, then another click to
dismiss the error message. Probably I should simplify it further.

>  * For X and kernel crashes (at least), these reports need to be
> indexable by hardware.  That is, we want to be able to answer both
> "how prevalent are GPU hangs on Intel hardware?" and "on what hardware
> does this GPU hang appear?".  Probably either DMI data or PCIIDs or
> both are needed for this.

I've added all of these to . (Not
saying that they're right or wrong, just as a base to work from.)

> While we're using the terminology "crash report", I want to ensure
> that there's a sufficiently general understanding of what this means.
> I think we'd want this to cover at least:
>  * Actual C-style crashes, with core.
>  * Unhandled exceptions, such as you'd get from Python et al
>  * Kernel oops and panics
>  * Intel GPU dump output
>  * dmesg & Xorg.0.log, triggered by GPU hangs
>...

Renamed from CrashTracker to ErrorTracker for that reason. :-)

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk5DqKEACgkQ6PUxNfU6ecpUXgCWO8vUtfc8B+NgN4S0QDCW/WUo
6ACfV6AT4G60kaag1M9UELI2HfNANkM=
=XR2s
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Computer Janitor to be removed from Oneiric?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Barry Warsaw wrote on 18/05/11 14:57:
>
> On May 18, 2011, at 03:34 PM, Martin Pitt wrote:
>...
>> Barry Warsaw [2011-05-18  9:23 -0400]:
>>>
>>> it says that Computer Janitor is to be dropped from Oneiric.
>>
>> It seems it was decided to drop it from the default CD install, but
>> certainly not from oneiric.
> 
> Okay!  That WFM :).  Thanks (and thanks Maco for the session link).
> 
> -Barry
> 
> P.S. I agree the UI could use a bit of DX love. :)

The DX team almost certainly don't have time to spend on anything except
Unity at this point. :-)

However, if it is possible to programmatically generate a list of
"packages you probably should remove" that does not often have false
positives like Computer Janitor does, I'd be delighted to see the
feature in Ubuntu Software Center.


- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3T30wACgkQ6PUxNfU6ecpeuQCfUd+9VCe7eVZeF0/s8nl5gq9V
uTwAn3pvQdDUGkffDNeyWQcFCxkSov80
=NJVm
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Default Desktop Experience for 11.04

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Pitt wrote on 14/04/11 14:54:
>...
> To the contrary. GtkStatusIcon is an official API from GTK, so people
> have every right to use it; we can hardly claim that it's a bug
> (although we have good reason to not recommend using it, of course).
> As I now kept saying for many times, as long as we don't get the
> indicator concept adopted upstream in GNOME/GTK (e. g. dropping the
> GtkStatusIcon in GTK 4), I don't see us having a good rationale for
> completely disabling them.

As you may know, one of the reasons libappindicator wasn't accepted into
Gnome was that "it doesn't integrate with gnome-shell".


Regardless of how good or bad that process was, it is not reasonable to
*then* say that Ubuntu application developers "have every right to use"
everything that's "adopted upstream in GNOME/GTK". That would mean
Ubuntu's APIs should be beholden to whatever Gnome Shell does or does
not need. And that way lies madness.

>> I doubt it's supportable to deal with Ubuntu patches for all the
>> relevant Universe packages.
> 
> Right, but that's not even everything. We are encouraging app
> developers to build software for Ubuntu using Gtk or Qt,

There's a good example. Qt includes a Qt::Drawer window type, for use in
Mac applications. Does that mean Compiz in Ubuntu should implement
drawers? Of course not. It might be suitable for Mac applications, but
it isn't suitable for Ubuntu applications. In the same way,
GtkStatusIcon might be suitable for Windows applications, but it isn't
suitable for Ubuntu applications.

>  and there's a
> lot of third-party software which should also work well on Ubuntu as
> well. Why did we make a concession for Skype and Java, but not for
> others?
>...

The concession for Skype is because Skype is proprietary (so we can't
fix it ourselves) and develops very slowly. I hope to meet with Skype
designers soon and discuss using an application indicator.

The concession for Java and Wine is because, unlike Linux application
developers, Java and Windows application developers can't reasonably be
expected to know or care about Ubuntu at all.

There is no bright line for what we should have included in the
whitelist or not. But the whitelist will shrink over time.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2v/TEACgkQ6PUxNfU6ecp5UgCeLBEpEYq5SGeJk8LS9FbSTd0k
euEAoMi3gvZe+uFXecMFICRAR2uocT0b
=0c5l
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Default Desktop Experience for 11.04 - User testing results

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jono Bacon wrote on 16/04/11 20:05:
>
> On Fri, 2011-04-15 at 03:00 +0100, Matthew Paul Thomas wrote:
>...
>> Last week, Charline Poirier ran a user test of Unity, with 11
>> individual participants. This week, I have helped Charline analyze the
>> results.
>...
> Wonderful work, and now very visible work:
> http://news.slashdot.org/story/11/04/16/0239213/5-Out-of-11-Crashed-Unity-In-Canonicals-Study
>  ;-)

Up to Slashdot's usual standards, I see.

To correct the obvious from that post:

*   No, "the results" of the study have not been published. Charline
will do that soon.

*   No, my name is not Rick Spencer. (rickspencer4?)

*   The object of the study was, obviously, not to measure crashes.
Crashes are usually quick to find and fix, so any user test of those
would be weeks out of date when published. I mentioned them only as
a reminder that to users, bugs are indistinguishable from design
flaws, and vice versa. (For example, one test participant pressed
Ctrl Alt F1 apparently by accident, and ended up at a console. This
wasn't a crash, but it had exactly the same effect as one.)

> I think this feedback points to a series of design and engineering bugs
> that we need to resolve in 11.10. Have the design bugs been filed in
> Launchpad?

Charline has been working with John Lea on that today.

> I think it could be worthwhile to rate the prioritization of the design
> bugs based upon the level of success in your study. As an example, if
> 1/12 achieved a task, it would be a high priority bug, as opposed to if
> 10/12 achieved the task it would be a low priority bug.
>...

I'll pass that on to John.

Cheers
- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2tokcACgkQ6PUxNfU6ecr1TgCePApLBm/ySLUAasdjINBrWQHs
LKYAoNLXk9mfWvVzz9fF7h4rl3eBq9u3
=j4k8
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Default Desktop Experience for 11.04 - User testing results

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rick Spencer wrote on 15/04/11 15:08:
>
> First, thanks Usability Team! I know how much work goes into planning
> and running a study like this, and how much agony is involved in
> interpreting and writing up the results. It's clear that there are some
> areas for improvement in 11.10, and these results will be instrumental
> in helping to guide those investments.

Charline did all the planning and test moderation. I was just the
stenographer afterwards.

Later on, Charline will publish a full report on the test. I just wanted
to post a quick summary in time to be helpful for the default experience
discussion.

> On Thu, 2011-04-14 at 22:48 -0700, Bryce Harrington wrote:
>>
>> On Fri, Apr 15, 2011 at 03:00:31AM +0100, Matthew Paul Thomas wrote:
>>>
>>> *   8/10 people could find a window's menus, but 7/8 of them learned to
>>> *   Only 4/11 worked out how to change the background picture.
>>> *   6/10 could easily find and launch a game that wasn't in the
>>> *   Only 1/9 (P4) easily added that game to the launcher.
>>> *   9/11 people could easily close a window.
>>> *   8/9 easily copied text from one document into another.
>>> *   Only 5/10 could easily delete a document
>>
>> These seven items in particular seem like really basic tasks that
>> ought to be testing at >90%, so these stats seem a lot lower than I'd
>> expect.

> Well, think back to the last time you got a new device. For example, if
> you have an Android phone. You are probably pretty facile with the
> interface now, but if someone handed it to you and said "do this task
> with it" you may have struggled to some basic things, like launching
> apps. A lot of the fun for users in getting a new devices is learning
> how to use it.

I didn't have anything close to that kind of trouble when trying out an
Android phone. (Though like anyone on a developer mailing list, I'm not
a representative sample.)

>...
> For brand new users? Some of the tasks aren't relevant.

Which ones?

>...
>> Also, these tests measure usability, but not their overall impression.
>> Did they like it?  Find it frustrating/confusing?
>
> This is actually a very important question. For me, when I go back to
> Classic, it feels very old and mundane. Many theories hold that the
> aesthetics trump usability, or at least strongly influence the
> perception of the usability of a system. In other words, given 2
> identically design systems that only differ in terms of theming, for
> example, users will rate the system with the more pleasing design to be
> more "usable" and are more likely to start using it. 
>...

This is the aesthetic usability effect.
<http://usabilityfriction.com/2010/03/30/aesthetic-usability-effect/>
<http://jnd.org/dn.mss/emotion_design_attractive_things_work_better.html>

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2oxq0ACgkQ6PUxNfU6ecoIcACcCcdaRX0LStM999wHOWz+q/GU
4YEAn05ZbWUmv1dPOkBJzHvpYb8eSaXg
=I/jZ
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Natty:Keyboard mapping selection comes to late during installation

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mackenzie Morgan wrote on 15/04/11 16:55:
>
> On Mon, Apr 4, 2011 at 8:51 AM, Alain-Olivier Breysse
>...
>> Keyboard mapping selection comes too late during installation. When
>> one wants to manually partition the drives on, for example, a
>> French-Canadian keyboard, the key mapping selection window hasn't
>> been presented yet (will be after the time zone selection) thus
>> obliging the user to manually call for that change which is not even
>> possible if Ubiquity as been started directly during the boot
>> process without selecting the "Try Ubuntu" option.
>...
> This late in the cycle, I doubt there are any pre-existing plans to
> change the order.  That said, changing the order should be pretty
> straightforward. Is there an open bug against which I could propose a
> patch?

There sure is. 

Thanks
- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2obtIACgkQ6PUxNfU6ecq/nwCgzOwTVylmcdxMJ9E57NRCp9mh
F0YAn26mUKLBy/Npmt2EwsyMIux3fw3X
=gOwl
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Default Desktop Experience for 11.04 - User testing results

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kate Stewart wrote on 15/04/11 05:52:
>
> On Thu, 2011-04-14 at 23:40 -0400, Scott Kitterman wrote:
>>
>> On Thursday, April 14, 2011 10:00:31 PM Matthew Paul Thomas wrote:
>>>
>>> In this summary, I have numbered the participants:
>>> - P1, 19, a student and Mac user
>>> - P2, 33, an administrator and Mac user
>>> - P3, 25, a student and Windows user
>>> - P4, 32, a teacher and Windows user
>>> - P5, 27, a compliance officer who uses both Windows and Mac
>>> - P7, 44, a life coach who uses both Windows and Ubuntu
>>> - P8, 30, an IT network manager and Windows user
>>> - P9, 22, a student and Windows user
>>> - P10, 21, a student and Windows user
>>> - P11, 47, a teacher and Windows user
>>> - P12, 34, an operations manager and Windows user.
>>
>> Would you characterize this as a reasonable (for it's sample size) 
>> representation of the target audience for Unity?

I've just asked Charline, and she says it is representative of the
target audience for Ubuntu.

> I'd also ask that a couple of folks 60+ (retired, new user to computers,
> as well as existing Mac and windows) be surveyed if possible. 
>...

In the past Canonical has run tests of Ubuntu with other specific
segments, e.g. 50-something women, but we haven't done that sort of
testing on Unity yet. (Of course, nothing prevents any other
organization from testing it with whoever they like.)

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2oM0cACgkQ6PUxNfU6ecoxYgCfWUNgH78JKGyro+us2jdIyntk
s3kAni6KlQUsNhHUXgQegzSduVGTsUlu
=Rupa
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Default Desktop Experience for 11.04 - User testing results

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bryce Harrington wrote on 15/04/11 06:48:
>
> On Fri, Apr 15, 2011 at 03:00:31AM +0100, Matthew Paul Thomas wrote:
>>
>> *   8/10 people could find a window's menus, but 7/8 of them learned to
>> *   Only 4/11 worked out how to change the background picture.
>> *   6/10 could easily find and launch a game that wasn't in the
>> *   Only 1/9 (P4) easily added that game to the launcher.
>> *   9/11 people could easily close a window.
>> *   8/9 easily copied text from one document into another.
>> *   Only 5/10 could easily delete a document
> 
> These seven items in particular seem like really basic tasks that ought
> to be testing at >90%, so these stats seem a lot lower than I'd expect.
> 
> I'm curious whether these stats are higher/lower/same-as with Classic
> Desktop.  IOW this needs a control group so we can tell if the new
> design brings improvement or regression.

Sure, that's the main problem with using this data. The test was
intended to find fixable problems in Unity, not to compare Unity with
Classic. And the tests Canonical has done on Ubuntu previously have
mostly been on other tasks, such as importing photos and music and
burning CDs.

> Also, these tests measure usability, but not their overall impression.
> Did they like it?  Find it frustrating/confusing?
>...

In my limited experience, user test participants can often be highly
complimentary about an interface that completely failed them (or
critical of an interface where they had no trouble). They can also start
guessing about what other people what other people might think, or
guessing about how easily they might learn something later.

That said, here's a representative sample.

P1: "I've got a Mac, and I think it's quite similar to a Mac, the
layout, which made it easier to use. I think people going from Windows
to this would need a little help, because it's a very different layout."
And: "It's a nice casual-ish font that you've used here."

P2: "I'm guessing the way it's set at the moment, with the wallpaper,
the background, I'd personally want everything to be crisper and clearer
and more obvious ... I find it all a bit blending into each other, with
those settings. But I do like the overall design of it, with the nice
curves and the nice icons at the side, and the font used, and the design
of it's really nice."

P3: "It's prettier than a lot of current operating systems." And: "I
don't think it's a complicated operating system ... it would just take
time."

P4: "Some of the features, like when you minimize something you don't
find the menu bar, so it's quite hard to find." And: "The simple is
quite simple, not too hard to follow or too hard to understand. If
possible, if you could give them a demo. This is where you go to get a
file, this is where you get all your icons, for the first time user,
obviously."

P5: "I really quite like it. I think it's quite intuitive, with the
exception of the favorites, making an application a favorite, which
obviously I wasn't able to achieve. I wouldn't be baffled about how to
use this operating system for the first time, if I didn't have a manual
to read ... It's quite clean-looking, it's quite modern-looking. It
seems to me to be closer to a Mac-style operating system than to a
Microsoft-style operating system."

P7: "No. I don't know. So at this point, I would have to say my initial
impressions are -- I wouldn't write it off, because I've heard too many
good things about it, but my initial impressions are 'Damn, I'm going to
need a manual' ... I don't really want to do that, which is a bit lazy
of me, I know." At the end: "It's not really working for me. I'm finding
it time-consuming and slightly confusing at times ... That's my kind of
bottom-line impression, really, that the differential [between Windows
and Ubuntu], the gap is really very big."

P8: "Maybe the settings should have been more prominent, but I found
them eventually. Fairly standard. If it can run anything I wanted, I
would consider it."

P9: "It's okay ... It's not as confusing as the Mac."

P10: "So generally I think it's pretty good. I think it needs some work
on it. I think making it a bit more intuitive."

P11: "Oh yikes, is it like Apple? ... I never liked the [Mac] interface.
I didn't know where I stored things, where I put things. I like these
pictures. It's aesthetically pleasing. It also looks like it's
child-friendly, because it's pictures. And it looks more ordered than
Apple. So I want to play with it now." At the end: &qu

Re: Default Desktop Experience for 11.04 - User testing results

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rick Spencer wrote on 08/04/11 02:38:
>...
> Back at UDS for 11.04 in Orlando, Mark set the goal of using Unity by
> default on the Ubutu desktop. Given the current course of development,
> it appears that we are going to achieve this goal, and Unity will stay
> the default for 11.04.
> 
> I'm following up on this list at the suggestion of the Tech Board to
> give folks a chance to respond or escelate any concerns.
>...

Last week, Charline Poirier ran a user test of Unity, with 11 individual
participants. This week, I have helped Charline analyze the results.

In this summary, I have numbered the participants:
- - P1, 19, a student and Mac user
- - P2, 33, an administrator and Mac user
- - P3, 25, a student and Windows user
- - P4, 32, a teacher and Windows user
- - P5, 27, a compliance officer who uses both Windows and Mac
- - P7, 44, a life coach who uses both Windows and Ubuntu
- - P8, 30, an IT network manager and Windows user
- - P9, 22, a student and Windows user
- - P10, 21, a student and Windows user
- - P11, 47, a teacher and Windows user
- - P12, 34, an operations manager and Windows user.

The test machine was a Lenovo ThinkPad T410i running Ubuntu Natty with
unity 3.8.2-0ubuntu1 and compiz 1:0.9.4git20110322-0ubuntu5.

Charline asked each participant to try several tasks. Not every
participant had time to try every task.

*   Every participant who was asked understood most of the launcher
items. P7 and P11 thought that "LibreOffice Calc" was a calculator,
and P7 and P9 thought Ubuntu Software Center was the Recycle Bin.
Nobody understood Ubuntu One. (The Classic session has much smaller
icons for everything, but has a visible-by-default label plus an
extra tooltip for each app.)

*   Almost everyone understood most of the indicators, but 4/11 people
(P7, P9, P11, P12) thought the Me menu icon might be a close button.

*   11/11 people easily launched Firefox to check Web mail.

*   8/10 people could find a window's menus, but 7/8 of them learned to
access them by hovering over maximized close/minimize/unmaximize
buttons then moving horizontally -- which was extremely slow, and
failed whenever the window wasn't maximized.

*   10/11 worked out how to open a new Firefox window, though 5/10 first
tried clicking Firefox in the launcher again, which didn't work.

*   Only 4/11 worked out how to change the background picture. This is
not as bad as it looks: for some of the others, Charline had asked
them *not* to right-click on the desktop, because she was testing
access to settings in general. Nevertheless, no-one found System
Settings, in the session menu or anywhere else.

*   Only 5/11 could easily rearrange items in the launcher. For the
other six, the main problems were that the launcher scrolled when
they were trying to drag an item, or that it didn't accept a drop.
(P10 was particularly unlucky in doing a Dash search for "menu" and
finding the Main Menu editor, which is useless in Unity but still
present by default.)

*   6/10 could easily find and launch a game that wasn't in the
launcher. (P2 deserves special mention for finding and launching the
game's .desktop file amongst piles of detritus in Nautilus's "File
System" search results.)

*   Only 1/9 (P4) easily added that game to the launcher. For the other
eight, the main problems were that the launcher disappeared when a
window was maximized or at the left of the screen, that Dash items
didn't have context menus, and that the launcher often didn't accept
a drop.

*   2/2 successfully removed an item from the launcher.

*   Only 2/6 noticed an XChat Gnome notification, despite (1) a
notification bubble appearing, (2) the Ubuntu button going blue,
(3) the messaging menu envelope going blue, and (4) an emblem
appearing on XChat Gnome's launcher.

*   9/9 easily launched LibreOffice Writer to write a letter.

*   5/5 easily found today's date.

*   9/9 easily saved their LibreOffice Writer document. (P1 recovered
amazingly well after trying to save "Letter to Mr Smith 08/04/11",
and getting the vile response "Error stating file '/home/ubuntu
/Documents/Letter to Mr Smith 08/04': No such file or directory").

*   9/11 people could easily close a window. The other two (P2, P7)
were not the only ones to be attacked by a bug that hid the title
bar for a window underneath the menu bar; they were just the only
participants for whom that bug really cramped their style.

*   9/9 easily found and opened an existing document.

*   8/9 easily copied text from one document into another. The other one
(P2) managed it eventually, but the missing title bar for one of the
document windows was again a major stumbling block.

*   Only 1/7 (P9, a Windows 7 user) easily arranged windows side by side
by discovering the window snap feature. (That's probably not reall

Re: Default Desktop Experience for 11.04

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Johansen wrote on 11/04/11 01:00:
>
> On 04/09/2011 12:21 AM, Allison Randal wrote:
>>
>> On 04/07/2011 11:52 PM, Martin Pitt wrote:
>>>
>>> If this is a major issue, then frankly I'd rather just remove the
>>> whitelist and allow all old-style systray applications than dropping
>>> Unity by default completely.

We've already done that. Now we're moving to the next step.

>> Yup, holding the vision for the future while addressing practical
>> concerns doesn't have to be all-or-nothing, black-or-white.

It's not all or nothing -- it's been a very gradual change.

In April 2010, we announced that we would be retiring the notification
area in Ubuntu 11.04.

In 10.04 and 10.10, Ubuntu allowed both notification area items and
application indicator items.

In 11.04, Unity reimplemented the notification area with a whitelist, a
whitelist that is longer than we originally intended.

In 11.10, if people have time to work on fixes for HPLIP and Mumble,
we'll be able to shrink the whitelist. (And by then we'll have a real
developer site, where ISVs can more easily find information about
application indicators and other Ubuntu APIs.)

> +1 its enough of a problem that some family members won't be making
> the switch to unity.

Can you be specific? Have you reported bugs on the applications?

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2m8wMACgkQ6PUxNfU6ecoZWACgiTY0qzNfrWIWUUQSGVltcdSL
/gAAoItl29U8s70QwgoFZXzeHd1/sIpx
=2OGj
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Bug Reporting Guidelines and Acknowledgement

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Murray wrote on 11/10/10 18:37:
>...
> The bug reported acknowledgement is a relatively new feature in
> Launchpad.  It appears on the reported bug's page in a notification box
> above the bug description.  With the Ubuntu bug reported acknowledgement
> I've taken the opportunity to ask the reporter to test with the
> development release[2] of Ubuntu:
>...
> [2] I realize this is less possible now
>...

That the very first acknowledgement text is useless in this way makes it
less likely that people will pay attention to any future acknowledgement
text. I suggest removing it until it can be useful.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky0MS0ACgkQ6PUxNfU6ecoCtwCfUzHHSUC0ReKt4ZPxajNKYV7o
W+UAoKHhPoOOnZlrYeLUa4zVZlwqplhk
=qdr5
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel