Re: [Feature Request] [RoF] Ubuntu Desktop - Inclusion of mdadm for RAID

[Matthew Paul Thomas]

Jeffrey Lane wrote on 22/04/2020 3:46 pm:
>…
> I can confirm that Ubiquity in Focal does not provide any means to
> create a software RAID setup.
> 
> Moreover, while it at least has some LVM ability, it does not provide
> the ability to create an LVM setup across multiple disks.
>…

In June-July 2012, I designed how Ubiquity could present RAID and
arbitrary LVMs. Unfortunately no-one has had time to implement either of
those features yet.

RAID:


LVM:


> Unfortunately, this is not going to happen for Focal it's WAY too late
> to make feature requests, that should have been done early on in the
> cycle.
> Renzo  could you please file a bug against 'ubiquity' requesting this
> support be added into the desktop installer?
>…

Lack of RAID has been reported as a bug several times.


And there are a few relevant bug reports for LVM.





-- 
mpt

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

Re: First boot animation can't be muted

[Matthew Paul Thomas]

Hello Simon

Simon Guilliams wrote on 02/06/2019 3:31 pm:
>…
> I am working full time in a _silent_ openspace. I was installing
> ubuntu and luckily I knew in advance that the animation would pop up
> with sound that you can't mute.
>…
> The animation is great... but really, the animation sound should at
> least be mute-able! The volume keys on the keyboard are ignored and I
> feel this is actually a bug. The animation is not skippable either.
>…
> What do you think about it?
> Is this ok for a bug report?
>…

I suggest two separate bug reports — one about the volume keys, and one
about the animation not being skippable. Those two issues would probably
be fixed by separate code changes, by different people, at different times.

Cheers
-- 
mpt

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

Re: A problem with licenses

[Matthew Paul Thomas]

Hello Tommi

Tommi Höynälänmaa wrote on 05/06/18 13:38:
> 
> I have published some software under GNU GPL and LGPL. However, when I
> open the Debian packages with Ubuntu Software Installation (18.04) the
> application claims that the software is proprietary. How can I fix this?
>…

Please report a bug on gnome-software:


-- 
mpt

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

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]

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 mailing list

Re: Software installation on modern Ubuntu

[Matthew Paul Thomas]

Colin Law wrote on 26/08/17 18:21:
>…
> OK, I see where you are coming from. It never occurred to me that
> anyone wanting to install libgtk2.0-dev, or similar, would want to use
> a GUI. I assumed everyone used apt for that.  Obviously I am wrong.
>…

Fonts are a clear example of packages that aren’t applications, but that
are much more pleasant to install with a GUI, since it can show you what
they look like.

-- 
mpt

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

Re: Software installation on modern Ubuntu

[Matthew Paul Thomas]

Nrbrtx wrote on 24/08/17 01:33:
>…
> As far I can understand here were two methods of software
> installation:
> 1. apt (apt-get), dpkg, aptitude - for advanced users
> 2. synaptic and Ubuntu software-center - for newbies.

Synaptic is fine for what it is, but it is not even close to being “for
newbies”. It doesn’t show the real name of any app (unless the name
happens to be mentioned in the description), it doesn’t show reviews or
recommendations, it doesn’t show screenshots until you click a “Get
Screenshot” button each time, and it prominently displays propellerhead
jargon like “multiverse”, “Mark All Upgrades”, and “Get Changelog”.

> Nowadays gnome-software and mate-welcome were added to the newbies'
> list. But they have very small lists of software.
> Ubuntu software-center was great, but its development was dropped.
> 
> What we have as result?
> 
> There is only one mature and functional software manager. It is named
> *Synaptic*. But ... it works very strange. I talk about Ubuntu 16.04.3
> LTS (!) here. I do not know why you migrated apt-xapian-index to
> Python3. This migration is incomplete and buggy (see bug 1612948

apt-xapian-index was ported to Python 3 because it was one of the tasks
necessary for porting Unity to Python 3.


It was also one of the tasks necessary for porting Ubuntu Software
Center to Python 3. Unfortunately other parts of that project were not
completed.

-- 
mpt

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

Re: Mirror sites should be only available via HTTPS

[Matthew Paul Thomas]

Erdos Pal wrote on 05/01/17 06:29:
>
> Hello,
>  
> is there a policy (or in planning) that the Mirror sites for Ubuntu
> related softwares should be only available via HTTPS?
> 
> It is 2017 and there is Let's Encrypt.
>…

I reported this in 2014, and mentioned the Let’s Encrypt possibility in
2016. 

-- 
mpt


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

Re: The Simple Things in Life

[Matthew Paul Thomas]

John Moser wrote on 19/07/16 22:48:
>…
> I've been repeatedly distressed and confused by this hidden boot
> process.  I've sat and waited at blank screens and splashes that give
> no feedback, wondering if the kernel is hanging at initializing a
> driver, trying to find network, or making decisions about a disk.
> There is no standard flow which can be disrupted with a new, non-error
> status message curtly explaining that something is happening and all
> is well; there is a standard flow in which the machine displays a
> blank, meaningless state for a fixed amount of time, and deviation in
> that time by any more than a few tenths of a second gives the
> immediate, gut-wrenching feeling that the system has hanged during
> boot and is terminally broken in some mysterious and
> completely-unknown manner.

You can press Esc to see the startup messages so far. But that works
only for people who know about it. And if your PC won’t start up,
showing *all* the text is a poor way of communicating what’s stuck. It
doesn’t tell someone what to say, for example, when phoning their techie
friend/relative for help. “The screen’s gone black and it’s full of
writing.”

> What Ubuntu needs most is a simple, non-buried toggle option to show
> the boot process--including displaying the bootloader, displaying the
> kernel load messages, and listing which services are loading and
> already-loaded during the graphical boot.

The current graphical startup, and showing all the startup messages, are
two extremes of communication. A setting to choose between those
extremes wouldn’t stop them from being extremes.

When displaying progress of a task, a good rule of thumb is: it should
look different at least every few seconds, but text shouldn’t change
faster than people can read it.

The looping startup animation fails the first part of the rule, because
it looks identical now to how it did ~4 seconds ago and ~4 seconds
before that.

And showing all the startup messages would fail the second part of the
rule, because usually they’re too fast for most people to read. (Not to
mention that most of those messages are not written with end users in mind.)

Ubuntu does a decent job of this when checking a disk during startup.
It’s something that will make the startup take much longer than usual,
so steadily-changing text appears together with the usual graphics.

This technique could be extended to the rest of the startup. Instead of
the dots, show a determinate progress bar (that is, one that fills up).
In addition, *if* the progress bar hasn’t moved at all in the past ~5
seconds, show the most recent startup message below it.

>   Ubuntu's best current
> feature is the Recovery boot mode, aside from not having a setting to
> make this the standard boot mode sans the recovery prompt.

I expect most people would rate a Web browser or a file manager as a
better feature than a Recovery boot mode.

>…
> Even Android displays a count of system assemblies AOT cached during
> boots after update so as to convey to the user that something is
> indeed happening.

A roughly equivalent bug for Ubuntu Touch is “hook into system-image
updates to precompile policy prior to reboot”
.

-- 
mpt

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

Re: Caffeine enabled by defect on Ubuntu 16.04

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martinx - ジェームズ wrote on 23/02/16 06:47:
> ...
> 
> On 22 February 2016 at 07:20, Matthew Paul Thomas
>> 
>> Ramon Marquez wrote on 16/02/16 19:42:
>>> 
>>> Caffeine is a package very important cause inhibits the screen 
>>> for playing videos on the web browsers. Actually is offered on 
>>> the main repository of Ubuntu 16.04 but disabled by default. I 
>>> think that Caffeine It should be enabled by default.
>> 
>> Fortunately, there is a much less bureaucratic and more reliable 
>> solution: the Web browser itself can tell Ubuntu to inhibit the 
>> screensaver.
> 
> This is also, very interesting! Seems to be a good solution, and 
> maybe more reliable...
> 
> However, it also seems odd to tell everysingle program out there, 
> to make a change, while Ubuntu can do this just once, in one
> place, for everything. Right?
> 
> ...

Ubuntu doesn’t have enough information to do this without instruction
from apps.

For example, a game’s menu screen, or a DVD’s menu screen, might
include a video looping in the background. If you leave either of
those screens for long enough, the screensaver should still activate,
because the video is not something the user will actively be watching.
(Especially if you fell asleep while watching the DVD, before it
returned to the menu screen.) Ubuntu can’t know this, because it
doesn’t know the purpose of the video. Only the app does.

Now, those kinds of video are the minority. So maybe it would have
made sense for the video frameworks to have the opposite default —
saying to apps, “I’ll inhibit the screensaver while playing, unless
you tell me otherwise”. But they didn’t, so app developers have to
remember more often. But at least that is far, far more reliable than
the Caffeine approach of expecting the user to remember to turn it on
and off (and be awake to turn it off) every time.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlbUFMMACgkQ6PUxNfU6ecrZKwCgozGjtIm+k8rRf3StDBXxe7xG
m5IAoKzgBioy7abQua/7GEiJkNyH53iY
=EFrq
-END PGP SIGNATURE-

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

Re: Caffeine enabled by defect on Ubuntu 16.04

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ramon Marquez wrote on 16/02/16 19:42:
> 
> Caffeine is a package very important cause inhibits the screen for 
> playing videos on the web browsers. Actually is offered on the
> main repository of Ubuntu 16.04 but disabled by default. I think
> that Caffeine It should be enabled by default.
> 
> ...

Fortunately, there is a much less bureaucratic and more reliable
solution: the Web browser itself can tell Ubuntu to inhibit the
screensaver.

This was implemented, for example, in VLC in 2013.


And in Firefox in 2014.


If it isn’t working for you with a particular Web browser playing a
particular type of video, please report a bug for that Web browser,
with exact steps to reproduce the problem.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlbK4OkACgkQ6PUxNfU6ecqFpACePJEsy091p4V06DADR+BVyXts
oIcAoL7TaH2GGyVvdFaFM6nm5719FCXS
=NVwh
-END PGP SIGNATURE-

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

Re: Disabling deb-src by default

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Usama Akkad wrote on 28/01/16 08:38:
> 
> Source packages are enabled by default. I've commented the deb-src 
> line from my sources.list file and that saved the update servers
> 16 hit (out of 87) when doing apt-get update One of the package for
> the sources of the universe repository was 7 MB.
> 
> ...

"Default sources.list file has source packages enabled by default"


Maybe someone will fix this bug before its tenth birthday.

I've catalogued other ways to speed up software updates.


- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlap8kEACgkQ6PUxNfU6ecofLACdEzmiONdqaANKkjmMKwgdhhJr
998AoMCZ+SurpKvlpbhVVKXJ+gUX0Gj9
=DNQk
-END PGP SIGNATURE-

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

Re: Proposal: Move Default Application Settings

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lars Kumbier wrote on 20/01/16 08:42:
> 
> Hi everyone,
> 
> currently, the settings for the "Default Application" are located 
> in "System Settings > Information > Default Applications", same as 
> the "Removal Media" settings.
> 
> I would not have guessed to find any settings behind a page called 
> "Information" at all when Unity was introduced and I believe, that 
> new users are struggling with that missing logic as well.

I guess by "Information" you mean "Details". (At least, that's what it
is in English in 14.04 and 15.10.)

Either way, though, yes, that panel is a junk drawer and System
Settings would be better off without it.

"Overview" would be more coherent as a standalone "About This
Computer" window. 

And "Legal Notice" would be more relevant as a dialog accessed from an
unobtrusive "ℹ" or similar button in the corner of the Dash itself.

> I propose to change the location of the "Default Application" 
> settings and the "Removal Media" settings to something more 
> suitable. The "Default Applications" setting would be better
> suited in the "Applications & Updates" page at first glance.

It's "Software & Updates", and I doubt many people would expect to
find default app settings there. That panel is about where Ubuntu
Software Center, Software Updater etc look for software and how they
behave.

Instead, I suggest combining "Default Applications" and "Removable
Media" into a single panel labelled "Apps & Devices" or similar.

> However, since both settings are bound to the user account, maybe
> a new page / icon in the "Personal" section of the system settings 
> would be better suited.
> 
> ...

"Personal" is not the same as "bound to the user account". For
example, accessibility settings and (currently) backups are bound to
the user account, but they are in "System". The categorization is
about how users think of the settings, not about whether they happen
to be user-account-specific.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlag/YUACgkQ6PUxNfU6ecrm6wCeOlZpZhluLBRPBzUqwxYcbIek
pl8An1s9Ux8erNMSQr4otCQO2BvKpWAJ
=ElP5
-END PGP SIGNATURE-

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

Re: Feature request: "Restart to ..." option

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

No one wrote on 02/11/15 12:09:
> ...
> 
> This feature would parse the entries in /boot/grub/grub.cfg, and
> list them in a menu called "Restart to...", next to Shutdown,
> Restart, Suspend, etc. So you could for example choose "Restart to
> Ubuntu 14.04 LTS" or whatever. After rebooting, the GRUB menu would
> be skipped and the chosen option would be loaded directly.

I designed something similar a couple of years ago.



I optimized for dual-booting, including only a button for restarting
into one other system. But if there are three or more systems, it
could be a combo button, with a menu listing the other options.

Ubuntu Light -- not the Ubuntu Light font, not the Ubuntu Light
themes, but the 2010-vintage Ubuntu Light "instant-on" environment --
included a "Restart Into Windows" button in its launcher.

So code exists to do this, somewhere.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlY7G8IACgkQ6PUxNfU6ecoqMgCgwJ1bLgeqRcbCN9g9CjwnWfEa
bLsAoMnOfwG+D6C4SKQSbB3HvEnEq8bL
=F6fA
-END PGP SIGNATURE-

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

Re: Getting ubuntu iso securely

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rune Schjellerup Philosof wrote on 11/09/15 07:48:
> 
> I am puzzled by the absence of a secure method of downloading the 
> ubuntu iso images. www.ubuntu.com is not served over https and 
> neither is releases.ubuntu.com.

I reported this as a bug in May. 

> None of the mirrors are using https.

This is a hard problem, because the mirrors are provided by
volunteers.  Requiring them to use
HTTPS would be an extra burden.

> I know that there are md5sum files and they are gpg signed as well.
> And if you search for it you might find 
> https://help.ubuntu.com/community/VerifyIsoHowto. But on 
> www.ubuntu.com there are no instructions reminding you to verify 
> the download.

Others in this thread have discussed various ways to make the md5sums
more prominent. But there are multiple problems with this approach.

No matter what we did, some people wouldn't see them or understand the
point. So they wouldn't protect everyone like HTTPS would.

Even if you did see and understand, you're probably on Windows, and if
you are, checking an md5sum requires downloading extra software.

Regardless of platform, the software usually runs on the command line,
which is off-putting.

Some graphical md5sum utilities are available, but most of them seem
to be downloadable only over HTTP, defeating the point. (If you're
willing+able to fake an Ubuntu download, you're willing+able to fake
an md5sum checker download too.)

Even if you find and learn the necessary software, then (as Ralf
Maldorf pointed out) the process is bizarrely complicated.

We could automate all this with a small Ubuntu-branded
downloader+checker (as suggested by Ryein Goddard), which was itself
downloaded over HTTPS. but that would require non-trivial
multi-platform software development. For example, the downloader would
need to deal with proxy servers.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlX5T+oACgkQ6PUxNfU6ecqy5gCfbtKZxCW7DydGRi97QfByNYOl
4qIAnRNEd7+biwWfpjC3X5x9IkmF8hjk
=rD8d
-END PGP SIGNATURE-

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

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! https://wiki.ubuntu.com/ContributeToUbuntu

- -- 
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: Suggestions for Ubuntu 16.04 LTS

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Leandro

Leandro Andrade Faria wrote on 18/06/15 16:52:
 
 ...
 
 I'm a Ubuntu user, former Ubuntu user actually, and I'm not a 
 developer. But I believe that some good suggestions might come from
 anyone, despite the ability to develop them.

That's true, but it's also true that ideas are cheap. If you look
through the bug tracker you will see that some of these have been
proposed and declined already. They would be more persuasive if there
was code or even a prototype to demonstrate them.

 It would be very nice and give users more freedom to customize 
 their Ubuntu desktops if:
 
 1 - Unity could allow the programs bar to me moved to all corners 
 (left - where it already is, right, bottom and top)

For example, this is Movement of Unity launcher
http://launchpad.net/bugs/668415.

 2 - Unity could allow users to change their theme collors without 
 changing the theme itself (we would be free to use Orange - witch 
 is standard, or green, grey, white, silver, purple, brown and all 
 the other collors)
 
 3 - Unity could allow users to change their folders' collors 
 disregarding the chosen theme collor. It could be na independent 
 choice.
 
 ...

And this is Make so the user can select color for folder icon
http://launchpad.net/bugs/202906.

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

iEYEARECAAYFAlWGoKQACgkQ6PUxNfU6ecqplgCfcjbsj7kWSM1K7iv6Wq0Y8weK
72UAmwTJcp9Axq1jf+Uv7k2ycDw/Jjuu
=vj2O
-END PGP SIGNATURE-

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

Re: [suggestion] Need a bar or wheel download for additional drivers in software updates

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

De Zan Chrsitophe wrote on 17/06/15 18:09:
 
 Good morning. There have months (years ?) when I go software 
 updates-additional drivers, I see only the sentence no
 proprietary drivers are in use...so I quite.
 
 First time this day, after a hazard wait, I see choice of drivers. 
 I understand than the phrase Drivers search available... is not
 just a phrase but an indication of work.
 
 I think than it need a bar or wheel download for indicate than the 
 system search drivers.
 
 ...

You are quite right, there should be a progress bar or spinner. I have
reported this bug for you. http://launchpad.net/bugs/1466479

Cheers
- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlWCtmUACgkQ6PUxNfU6ecrJzQCeIcXsVrIYPF5P7Jh55W0ZpCxc
grIAoL4yXGW8JoTHSPg5Omtcfoo8UqPk
=W1UZ
-END PGP SIGNATURE-

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

Re: Account Management / Shared Secret Generator

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Titke wrote on 11/06/15 15:42:
 
 I propose to include my Internet account password creation scheme 
 into the current account / password / keychain management systems 
 on Ubuntu.

That would be excellent!

 Whenever you would like to do something very very important you 
 probably will need a new password for subscribing to a mailing 
 list, creating another online account and else. After some
 password you start to develop a scheme on how to easily create new
 passwords but it remains daunting. The password storage and
 retrieval is already done by Firefox, Thunderbird, Key Chain and
 Account Managers but the password creation is still left to the
 user who - as a matter of fact - only needs to memorize his master
 password.
 
 To fill the gap I have written a small command line utility in 
 Guile Scheme which serves my needs. For those interested I
 attached the program. But I would like to see this feature
 incorporated into the existing solutions in the open source world.

Think of the funnel that people need to go through, to benefit from a
password generator. Broadly, they need to do four things:

1. Notice that the generator exists.

Probably 90%+ of the time that people choose a new password they are
concentrating on a Web page. So to be noticeable, you'll need to embed
a button directly into the Choose password: field on that page. So
you'll need a browser extension. (The extension should look for
forms that contain at least two input type=password fields; the
penultimate one will be a Choose password field. There may need to
be a maintained list of popular sites that flout this heuristic.)

That leaves native apps. To make your generator noticeable in those,
you'll need to provide it as part of the password field control in
toolkits for app developers to use. Here you have three problems to
tackle: language, toolkits, and adoption. Language: Writing in Scheme
is of little benefit as long as Guile doesn't ship by default.
Toolkits: Ubuntu suffers from toolkit proliferation, in that we ship
apps with password fields in GTK (e.g. file-roller's Compress
dialog), XUL (Firefox and Thunderbird), VCL (LibreOffice's File 
Properties  Security  Protect), and soon QML (Ubuntu Touch
apps). The more toolkits you cover, the more work it will be, but the
more often people will be able to recognize and use the feature.
Adoption: Persuading app developers to adopt the toolkit feature once
it is implemented and shipping. More difficult for cross-platform apps.

2. Be interested enough to use it.

3. Be confident that they'll be able to use the password later.

These are interface design problems. The generator needs to be not
just easy to use, but satisfying to use (look up the research on the
psychological effects of password strength meters), and reassuring in
letting you know how you'll access the password later. Compare the
competition -- some designs are much better than others.
https://helpdesk.lastpass.com/generating-a-password/
http://www.roboform.com/tutorial-password-generator
http://blogen.stickypassword.com/creating-strong-passwords-with-sticky-password/
https://www.google.com/search?tbm=ischq=keepass+password+generator

4. Actually be able to use the password later.

Here you defer to other apps. But it doesn't matter how great your
password generator is, people probably won't use it if they can't then
log in to the same service on their Windows/Mac PC, iPhone, Android
phone, or even Ubuntu phone. So to be reliable, the system needs to be
not just multi-app, but multi-platform, and automatic in syncing
passwords between devices. And I'm not aware of an open-source system
that meets those three requirements. Ubuntu's Passwords  Keys
(Seahorse) from Gnome is multi-app but single-platform. KeePass is
multi-app and multi-platform, but syncing is tediously manual. And
Firefox Sync is multi-platform-ish (no longer on iOS) and automatic --
but it's single-app, in that (as far as I can tell) it works only for
passwords inside Firefox.

None of this is to put you off, I'm just sketching a map of the terrain.
If all you want to do is integrate your generator with what Ubuntu has
right now, you could port it from Scheme to a language we ship, and
add a new dialog to Seahorse ... but few people would notice. If you
have a more substantial goal -- to noticeably improve the quality of
Ubuntu users' Internet passwords, say -- the first thing I'd tackle
would be the device syncing problem. That could help people who are
using KeePass right now, as well as influencing the architecture of any
parts of the problem you work on later.

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

iEYEARECAAYFAlV9ec8ACgkQ6PUxNfU6ecquCACgx91jrILnzc0wCeJNr+AUSc2n
efcAoJYE90cpFyBYEG7MWkRJISGUdkRb
=igW7
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 

Re: Account Management / Shared Secret Generator

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Titke wrote on 14/06/15 15:28:
 
 On 14/06/2015 14:55, Matthew Paul Thomas wrote:
 ...
 
 None of this is to put you off, I'm just sketching a map of the 
 terrain. If all you want to do is integrate your generator with
 what Ubuntu has right now, you could port it from Scheme to a
 language we ship, and add a new dialog to Seahorse ... but few
 people would notice. If you have a more substantial goal -- to
 noticeably improve the quality of Ubuntu users' Internet
 passwords, say -- the first thing I'd tackle would be the device
 syncing problem. That could help people who are using KeePass
 right now, as well as influencing the architecture of any parts
 of the problem you work on later.
 
 ...
 
 First of all porting the algorithm is not enough because it 
 constitutes some kind of black box test of your deterministic 
 implementation of /random/. Second it's easier to port things to 
 Scheme with Parallel Objects (just try it with Racket for now)
 than to bump my mind down to C level et al. Third: I'm just
 throwing the seeds here ...

I'm not a programmer, and I'm sure Scheme is just lovely, but I can
see that you're getting a seed from /dev/urandom and mapping it into a
string of random characters. Doing that in C might be nerve-wracking
(since it's security-sensitive code), but I doubt more than a few
hours work.

 If it isn't enough to communicate the idea to the open source
 world then probably it's not worth changing one dozen toolkits, 
 applications etc.

Open source is not magic. In open source just as in closed source,
ideas are cheap, code is expensive, organization is priceless. As I
outlined, improving the quality of Ubuntu users' passwords would
require a lot of organization. That doesn't mean it isn't worth doing.

 This time there even is a reference implementation but what about
 your users: IMHO open source means to open a text file to change
 the behavior of a program (which resembles the descriptions of LISP
 machines) whereas others think it as managing a community to do
 the work o to not provide easy to compile source packages etc.

Open source is a license to redistribute, not a license to configure
or a license to direct other people's work.

 The next step isn't GTK, GNUstep - but it should be something where
 is system startup boils down to a maximum of 500 lines of System
 Scheme.

That depends on your objective. Do you want to provide a password
generator that a non-trivial number of Ubuntu users will use? Or do
you want to write an OS in Scheme? Both are fascinating objectives,
but only one of them is relevant to this mailing list.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlV9waEACgkQ6PUxNfU6ecphPQCgiYT3hxnuKsbt7+xXBg3uAlJa
WoYAnRARpM9/ugyO8u4BnGORR6CrWfR4
=VH9X
-END PGP SIGNATURE-

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

Re: Window Controls on the Right Side

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

john.r.mo...@gmail.com wrote on 14/05/15 04:06:
 
 On 05/01/2015 10:52 AM, Matthew Paul Thomas wrote:
 
 ...
 There have been dozens of desktop computer OS manufacturers less 
 successful than Apple -- for example, Acorn, Be, Commodore, 
 Google, IBM, Sun, and every company that has ever released an OS 
 based on Gnome or KDE. Broadly marketed is assuming the 
 question -- the
 
 For decades? Standing side-by-side with Dell in Best Buy and 
 CompUSA? With their own stores?  All over the news, pervasive 
 throughout culture?

You are assuming exactly the same question again. That they were less
successful is precisely why they weren't broadly marketed for decades.
And that has pretty much nothing to do with window controls.

 ...
 
 Back in 10.04, Ubuntu tried moving the controls to the left. 
 This met with huge resistance, largely in the form of 
 complaining, whining, and people putting the controls back 
 where they belong.
 
 That is similarly assuming the question. The only reason you 
 think the controls ... belong on the right is that around
 1993, someone at
 
 I have given the ergonomic definition.

Which makes several unfounded assumptions. Most notably, that more
users of Ubuntu -- which was originally focused on notebooks, and has
always been preinstalled most often on notebooks -- use mice (where
rotating to the right may indeed be easier) rather than touchpads,
trackballs, and pointing sticks combined (where extending a bent
pointing finger to the left is probably easier). And that window state
changes are more frequent and/or hurried than other functions that
could occupy the same area.

 In both Windows and OS X, putting the controls all on one side 
 (a) increases the risk that you'll close a window when you mean 
 to minimize or maximize it,
 
 The argument is about putting all the controls on the left instead 
 of the right.  In that context, you risk closing the window when 
 you operate the locally-integrated menu.

You are still assuming that all the controls belong on one side at
all. I was demonstrating that that assumption, too, is unfounded.

 (b) makes centered titles look imbalanced in the title bar,
 
 No different if all controls are on the left; and, generally, the 
 least-important thing anyone could say on the topic.

Again, you are wrongly assuming that all controls are on one side or
the other.

 and (c) causes ugliness when a window doesn't have maximize 
 and/or close functions, because you end up with buttons that are 
 either permanently insensitive (as in Windows and OS X) or 
 inconsistently-placed (as in Ubuntu).
 
 This is not solved by moving buttons around.

Yes it is, if there is one subtle extra rule: an unminimizable window
can't be maximizable either. Then if you have minimize and close at
opposite ends, and maximize next to minimize, all the possible
combinations of those three controls avoid all three problems I described.

 ...
 
 Apart from the Fitts's-Law-derived conclusions that the easiest 
 pixels to hit are (a) the one you're at right now and (b) the 
 four corners, I'm not aware of any research on this. Do you know 
 of any?
 
 Hold your right arm out straight in front of you, with the fingers 
 extended in line with the forearm.
 
 Now, tilt your wrist thirty degrees to the right.  That's easy, 
 yes? It's a wide range of motion.

Again, you're assuming that most Ubuntu users use mice.

 ...
 
 A year later, in 11.04, Ubuntu released the Global Menu. Three 
 days before 15.04, Ubuntu reversed a decision to disable the 
 Global Menu by default, after preening themselves with talk 
 about the new Locally Integrated Menus--i.e. pre-11.04, 
 non-Apple menus.
 
 As far as I know, there was no decision to disable global
 menus by default in 15.04, it was just a mistake.
 
 They accidentally set bug #1412297 as Fix Released as well.

As is clear from the bug report, it was supposed to be Kylin-only.

 Locally Integrated Menus are a red herring: they don't solve the 
 primary problem of menus being invisible by default.
 
 Long ago, I went on some long rant about multiple mouse clicks 
 required to access a visible window's menus when using global 
 menus. Nobody believed me.

Maybe it was something to do with it being a rant.

 You suggest the intellectually disjoint argument that every 
 window's menu should be visible by default, but that putting the 
 menu in the window is the wrong solution.  This is a generous 
 assumption on my part:  all other things you could possibly
 suggest would be ridiculous, and indicate a deluded mind afflicted
 with some form of mental illness.

Then this is the single most important thing for you to learn from
this exchange: If it seems that someone is either intellectually
disjoint or mentally ill, your first hypothesis should be that you
misunderstood them. Because if you suggest either of the other two --
or even worse, both -- and you're wrong, you'll look like a churl

Re: Window Controls on the Right Side

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Moser wrote on 30/04/15 03:23:
 
 ...
 
 First and foremost, the biggest red flag you'll ever find in the UI
 design sphere is Apple blahblahblah.  This statement comes out of
 people who have no clue what they're talking about, so make an 
 appeal to authority--typically the authority of the 
 least-successful product produced by the least-successful desktop 
 computer OS manufacturer.
 
 Folks seem to forget that Apple's OSX is the only broadly-marketed,
 consumer-targeted alternative to Microsoft Windows, and is
 completely trounced by them;

There have been dozens of desktop computer OS manufacturers less
successful than Apple -- for example, Acorn, Be, Commodore, Google,
IBM, Sun, and every company that has ever released an OS based on
Gnome or KDE. Broadly marketed is assuming the question -- the
reason many of the systems are no longer marketed is that they were
unsuccessful. Success or failure of an OS is not so much a red flag as
a red herring: generally, Windows has demonstrated that good design is
not necessary for success, while OS X has demonstrated that it is not
sufficient.

 Back in 10.04, Ubuntu tried moving the controls to the left.  This 
 met with huge resistance, largely in the form of complaining, 
 whining, and people putting the controls back where they belong.

That is similarly assuming the question. The only reason you think the
controls ... belong on the right is that around 1993, someone at
Microsoft decided to add a close button alongside the minimize and
maximize buttons on the right of windows in Windows. This change showed
up in Encarta 95 on Windows 3 (flouting the standard of where the
controls belonged on Windows, rabble rabble!), and then in Windows
95 and later. From then until OS X in 2001, Windows was pretty much
alone in having all its visible window controls on one side of the
title bar. For example, Mac OS 7~9, AmigaOS, BeOS, and twm all split
the controls across left and right.

In both Windows and OS X, putting the controls all on one side (a)
increases the risk that you'll close a window when you mean to minimize
or maximize it, (b) makes centered titles look imbalanced in the title
bar, and (c) causes ugliness when a window doesn't have maximize and/or
close functions, because you end up with buttons that are either
permanently insensitive (as in Windows and OS X) or
inconsistently-placed (as in Ubuntu). These problems could be avoided
by splitting them across left and right, as Canonical's then-head of
design suggested: Personally, I would have the max and min on the
left and close on the right.
https://web.archive.org/web/20100315143609/http://www.ivankamajic.com/?p=281

If we *were* going to put them all on one side, the right would be a
bit easier, for Windows refugees to migrate to, than the left would.
That's a valid reason that is obscured by talk of where they belong.

 ...
 
 I said most people are right-handed, and that the easiest way to 
 tilt your wrist or move your arm was out and away.  The top-right 
 of your screen is the easiest area of the screen to access--go 
 ahead, try it. Those of us with civil rights in Elbonia will find 
 I'm completely correct; lefties will find confusion, followed by 
 the realization that they're using the wrong hand.

Apart from the Fitts's-Law-derived conclusions that the easiest pixels
to hit are (a) the one you're at right now and (b) the four corners,
I'm not aware of any research on this. Do you know of any?

 A year later, in 11.04, Ubuntu released the Global Menu.  Three 
 days before 15.04, Ubuntu reversed a decision to disable the
 Global Menu by default, after preening themselves with talk about
 the new Locally Integrated Menus--i.e. pre-11.04, non-Apple menus.

As far as I know, there was no decision to disable global menus by
default in 15.04, it was just a mistake. Locally Integrated Menus are a
red herring: they don't solve the primary problem of menus being
invisible by default. Last month's SRU introducing the
com.canonical.Unity always-show-menus setting is a first step toward
solving it, but long-term, having a setting for something like that
would demonstrate indecision.

 ...
 
 First, if the window is maximized, the menu is obviously in the 
 same place on the screen.  If not, you have multiple windows, and 
 it takes *two* *mouse* *clicks* to click a menu.

That isn't correct. It takes 1 + n clicks, where n = the probability
that the menu item you want is for a window different from the focused
one. So, probably about 1.1 clicks on average, varying depending on
the kind of work you're doing.

 With LIMs (you know, *normal* menus), you just click File on the 
 window; with Global Menus, you have to click the window, then go 
 back and click File at the top.

That isn't correct either. Locally Integrated Menus are not normal
menus; menus in the title bar are unlike Windows, OS X, or any other
system or app I've seen, except the eccentric 

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
http://launchpad.net/bugs/254584.

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. :-)
https://wiki.ubuntu.com/ContributorConsole#updates

- -- 
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: mail binary from mailutils package 1:2.99.98-1.4 doesn't expand aliases

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tom H wrote on 30/01/15 13:17:
 ...
 
 There's already a bug so filing another report isn't really
 useful.

Sorry, I had looked at the bug list, but didn't notice that one was
the bug Jean-François was talking about.

 It looks like this bug is [1] and it's unclear whether it's a
 feature or a bug that mailutils' mail doesn't use aliases declared
 in ~/.mailrc.
 
 A workaround seems to be to use bsd-mailx's mail.
 
 [1]
 https://bugs.launchpad.net/ubuntu/+source/mailutils/+bug/1222181

The next step is to see whether the bug occurs in upstream mailutils.
http://mailutils.org/download.html

If so, report a bug there
http://mailutils.org/manual/html_section/Reporting-Bugs.html#SEC252,
then record in Launchpad that you've done it.
https://bugs.launchpad.net/ubuntu/+source/mailutils/+bug/1222181/+choose-affected-product

If not, then it's a bug specific to the Ubuntu packaging. The next
step might be to see if it also occurs in Debian mailutils.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlTQi+sACgkQ6PUxNfU6ecrStwCdEkzgw7eFxjAcB38eUXqr6xVM
SHAAnj6lRU8Hv60Fi0blKvND9Tfqvz0s
=N4Kf
-END PGP SIGNATURE-

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

Re: mail binary from mailutils package 1:2.99.98-1.4 doesn't expand aliases

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

jfprev...@bluewin.ch wrote on 21/01/15 23:17:
 ...
 
 This bug has been filed in 2004 in the debian bugtracker, but 
 apparently closed by the maintainer as he couldn't reproduce it. I 
 confirm that on my Ubuntu 14.04 LTS 64bits, the aliases declared
 in my home folder's .mailrc are not expanding. For example, if I 
 declared a line alias jfp j.f.prev...@free.fr then when using
 the mail jfp comFor example, when declaring a alias jfp 
 j.f.prev...@free.fr statement in my .mailrc file then when
 calling mail -s TEST jfp then the mail is sent with
 jfp@localmachinename (localmachinename being my linux system's
 local host name) which is not correct and should not be. Please
 (re)open a bug for this case until it gets *really* fixed.
 
 ...

Bugs are best reported by someone who is willing and able to reproduce
them.

I suggest you get a Launchpad account, https://launchpad.net/+login
then report the bug yourself. You can do this starting from a
terminal, by entering ubuntu-bug mailutils (without quotes).

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlTGJMQACgkQ6PUxNfU6ecoEJwCfbTfHBvnys/ZkUofolrRSI89H
kA4AnR2rGlgTYESZkRggdAe/UUCc2xvM
=2CE/
-END PGP SIGNATURE-

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

Re: Updater can't update kernel due to disk space

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Knutson wrote on 14/01/15 15:34:
 
 Clearing out old kernel versions manually to be able to upgrade
 the kernel version is something the end user should never have to
 do. Clearing out old kernel version from /boot should be better
 managed by the software updater to intelligently manage historic
 kernel versions based on available disk space on the partition.

software-updater refuses to upgrade, needs a button to clean /boot
http://launchpad.net/bugs/1389620

Please consider enabling
Unattended-Upgrade::Remove-Unused-Dependencies by default
http://launchpad.net/bugs/1294195

Mateusz Stachowski wrote on 15/01/15 20:21:
 ...
 
 The 'apt-get autoremove' doesn't work for me. I only get the extra 
 images remove the generic and headers are still there and I need
 to remove them manually.
 
 ...

Kernel updates are being marked as manually installed
http://launchpad.net/bugs/1175637

'Unattended-Upgrade::Remove-Unused-Dependencies' does not work
http://launchpad.net/bugs/1267059

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

iEYEARECAAYFAlS+aRQACgkQ6PUxNfU6ecq3ugCfZtFwp9BbiBcI0K1n8f4WMl/o
0SgAmwduWrQ9Ptrr32+hFeqGDn4NlC25
=6Ca0
-END PGP SIGNATURE-

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

Re: Feedback and Bug App

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Alexander

Alexander Langanke wrote on 12/12/14 22:22:
 ...
 
 I recently installed the Windows 10 technical preview on my
 windows machine and have played around with OS X Betas in the past
 and really liked the feedback apps they both have and the insider
 hub that windows 10 recently recieved.
 
 Why don't we build something similar for Ubuntu? We have apport as
 a bug info collecting tool with no real GUI and no feedback tool 
 whatsoever (that I am aware of). The Ubuntu Test Cases could get
 some more stagetime as well.
 
 ...

I designed a Contributor Console for Ubuntu on PC a couple of years
ago. https://wiki.ubuntu.com/ContributorConsole

Michael Spencer started implementing it, but it hasn't been touched
for a while. https://code.launchpad.net/contributor-console I'd be
delighted to see it finished and published in the Ubuntu archives.

 Do plans for something like this exist? If not, and you deem this
 a not useless/obsolete idea, what would be the preferred way to
 start? A native App or a web app that integrates the relevant
 launchpad sites or perhaps a scope?

Adapting the app to work on Ubuntu Touch would be tricky, because it
would need access to several things (such as the list of other running
apps, surfaces opened by those apps, and input to those surfaces) that
Ubuntu Touch does not allow. The OS would need to grant an exception
for this app. I expect that would be much easier if it was a native
app than a Web app.

On the other hand, that Ubuntu Touch apps are implemented in only
(ahem) three toolkits -- QML, HTML, or the Dash toolkit -- would allow
features that would work much more often than on Ubuntu for PC. For
example, you could triple-tap on a text label in any app to report a
bug about, or improve the translation of, that particular string.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlSO1jwACgkQ6PUxNfU6ecoBNwCgsrLdle4yeVVBLmbpI4sPeq7H
lGsAnR/CqUCAv8tPox2rqxw9ZcVamEzD
=GxhY
-END PGP SIGNATURE-

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

Re: Ubuntu Software Center future

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tim Heckman wrote on 28/09/14 23:32:
 
 On Sun, Sep 28, 2014 at 4:11 AM, David Raphaël
 raphael.da...@epfl.ch wrote:
 
 However, I am a bit concerned about package management and I
 think that Ubuntu should develop (or improve) its own package
 management system in order for the distribution to be more
 administrators friendly.
 
 I'm sorry, but you can't cite an improvement in the GUI as being
 more administrator friendly. As an administrator of a sizeable
 Ubuntu fleet, dpkg/apt does everything I need it to. It's quick,
 it's reliable, and I've never had it break my system unless I had
 already done something stupid... Tried and tested with minimal
 magic.

Right. If you're an administrator who does need a graphical interface
(for installation profiles and repositories, for example), try Landscape.

 There are plenty of people I know who administer Ubuntu systems are
 actually turned-off by the desktop-centric vision. So be careful.
 
 I'm basing my assertion that Ubuntu is desktop-centric based on 
 previous decisions that shipped.

On any given day, the front page of Ubuntu's Web site is more likely
to highlight server/cloud features (Juju, Openstack, Landscape) than
desktop ones.

 ...
 
 If it's not broke, don't fix it.
 
 I think they are more than welcome to add a UI around either
 dpkg/apt, but they should not develop their own package management
 system. To put it bluntly, it would be a stupid decision.
 
 ...

In 1999, dpkg/apt was amazing. By today's standards, it is broken.
Maintainer scripts can do anything, which means there is no reliable
undo function, no sandboxing, no user-only installation, and the
package system can be corrupted merely by disconnecting the power
during an update. When an error does occur, apt returns only localized
error messages, effectively preventing any higher-level tool from
presenting tailored troubleshooting options. The entire apt package
list is stored on the client, which makes checking for updates slow,
and wouldn't scale to hundreds of thousands of apps. And every package
in the world is required to have a unique name, which doesn't scale
even to tens of thousands of apps.

- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlQqfAMACgkQ6PUxNfU6ecpNcwCfYACJf4RHTKvZACRu4t3S33w+
j4gAoJD5NGMnd1HtwbgcfiGq5R5w0wZ5
=xaGD
-END PGP SIGNATURE-

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

Re: Dropdown menu problem.

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Joshua

Joshua Katz wrote on 19/08/14 21:57:
 
 Hey I'm new to this mailing list and I am not sure if this is the 
 correct place to ask this but I was wondering if there where plans 
 to implement Bruce Tognazzini's dropdown menu fix into the Unity 
 menu system. The fix is detailed here: 
 http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown

...
 
Well spotted! This mechanism was introduced in GTK menus around May
2000, and it worked in every version of Ubuntu until 13.10.
https://mail.gnome.org/archives/gtk-devel-list/2000-May/msg00120.html

It was broken upstream in July 2013, and will need to be fixed there.
https://bugzilla.gnome.org/show_bug.cgi?id=710388

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

iEYEARECAAYFAlP1p3EACgkQ6PUxNfU6ecqdyACgxWCXXudCo/YDAKkIbeWqTnaB
6VAAnj6SWPlOqDuKOdyYL8xGQWBJSqox
=JkEO
-END PGP SIGNATURE-

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

Re: Pre-upgrade warnings and advice?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Neal McBurnett wrote on 02/06/14 20:49:
 ...
 
 Is there anything in the official upgrade tools to remind users 
 about use of ppas, non-repo packages, unofficial desktops or other 
 potentially problematic bits of software like unofficial programs 
 which tweak UI settings and the like?
 
 I recall some warning about some such packages at upgrade time,
 but I forget when it happens, what it includes, and what advice it 
 gives.

The alert appears after the release notes, and before the new packages
are downloaded. It has primary text Third party sources disabled,
and secondary text Some third party entries in your sources.list were
disabled. You can re-enable them after the upgrade with the
'software-properties' tool or your package manager. It has one
button, Close.

There are several problems with this. Is it really necessary for the
sources to be disabled? Does that mean software from those channels
will be removed too? If so, which software is involved? And if not, if
a security update is issued in that third-party source later on, am I
just out of luck? Why is there no button for cancelling the upgrade at
this point? And if I cancel the upgrade after this point, do the
sources remain disabled, and if so, why?

Even if the function is unchanged, the presentation could be improved
in many ways. Why am I exposed to the filename sources.list, when I
probably added the channel through Software Sources without seeing
that filename? What is an entry, and what does it mean for it to be
disabled? Which ones were disabled, exactly? Why is a graphical tool
referred to by its command-line name? Why is it using Ascii
apostrophes instead of quote marks? And what is a package manager?

 It would seem most convenient to have a safe, stand-alone 
 application that would just look for such software and give good 
 advice on what might not work, where folks might go or look for 
 upgrade paths supported by PPA developers or other organizations, 
 etc.  It would help a lot if it didn't spew out too much 
 information, e.g. by combining warnings for a set of packages into 
 an overall warning about a particular desktop or suite of related 
 packages with similar upgrade issues.
 
 ...

Why would it be most convenient for it to be a standalone application?
That would mean that most people upgrading wouldn't see it and
therefore wouldn't benefit from it. And if it was intended for use
outside the upgrade process, that's what Software Sources is for. It's
already a Windows-Vista-like awkwardness that Software Sources is a
standalone app instead of a System Settings panel.

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

iEYEARECAAYFAlORxkUACgkQ6PUxNfU6ecoznQCfUakY111ONW34sV4wsfphdIFH
4EwAoLuKMvJYZSO668vIRagJz9PrTbes
=5FBH
-END PGP SIGNATURE-

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

Re: User-friendly HRTF

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tiago Matono wrote on 20/05/14 21:16:
 
 Hi. So today I tried the openal HRTF. It works wonderfully! All my 
 games and movies play with awesome 3d sound through my headphones.
 To activate it I simply ran echo hrtf = true  ~/.alsoftrc  in
 the terminal as explained here: 
 http://www.bitoutsidethebox.com/shabda/hrtf-info/
 
 Why is this so easy-to-implement function not included somewhere
 in ubuntu through a simple checkbox?

Probably because no-one has yet had the combination of interest,
ability, and time to do it.

If you're trying to recruit someone to do it, I suggest being more
specific about what it would achieve. Even the Wikipedia article is
heavy on jargon and rightly says [example needed].

 Can this be implemented? Maybe a simple checkbox under sound
 settings that would only appear and be activateable when
 headphones are connected. I think this is an awesome and easy to
 implement feature.
 
 ...

Settings are useful only as much as people can make an informed
decision about them. So before we could design a checkbox like that,
we would need to answer the question: Who would want HRTF turned off,
and why? Or to put it another way, why not just have it turned on for
everyone?

- -- 
mpt

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

iEYEARECAAYFAlN8XAsACgkQ6PUxNfU6ecoBigCfYNF7uUAcKSpW9bbvK5E1Ne+3
XeoAn0yCykfl0nkKliKXooEEbJyqO8+u
=vROf
-END PGP SIGNATURE-

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

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 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 ones we 
 know exist at all. So the denominator is much too low -- making 
 the calculated error rate much too high.
 
 Thus the nice charts we are plotting on the page are mostly useless
 and neither help me find the most common issues of my package or
 the distro in toto[2].

The charts have never been intended for finding the most common
issues. They don't even mention any particular issues. The charts are
intended for answering question #1 in the rationale
https://wiki.ubuntu.com/ErrorTracker#Rationale: How reliable is
Ubuntu right

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. https://twitter.com/mpt/status/265371407154835456

 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

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

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. http://launchpad.net/bugs/1201396 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. ;-) http://launchpad.net/bugs/1069827

 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
just as bad whether it happens during an upgrade, during a 

Re: apt and pdiff files

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

staticd wrote on 02/03/14 04:50:
 
 Is this and EWONTFIX or a EBUSY? it will be nice if responses to 
 queries clearly distinguish between the two. ;)
 
 ...

I'd like us to do pdiffs, but there's a bit of a shortage of
implementation time seems pretty clear to me.

Anyway, here's the relevant bug report. http://launchpad.net/bugs/214612

- -- 
mpt

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

iEYEARECAAYFAlMUQ5AACgkQ6PUxNfU6ecpWqgCfQkj8PKQqo/y8oOO0hvcUZM7m
XPwAoKPsIFlbNaUXK2wP5HBnDTaY/Kx6
=F31C
-END PGP SIGNATURE-

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

Re: Ignoring privacy sabotages Ubuntu's best chance for success

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gerry A. wrote on 25/02/14 17:29:
 
 I have two specific improvements I would like to see in Ubuntu. 
 Thanks for mentioning this.
 
 #1 is the ability for users to uninstall elements that send their
 data onto the internet as it relates to Dash searches. 11.10
 appears to allow users the ability to uninstall scopes. But there
 is no way to uninstall the capability for Dash searches to be
 transmitted onto the internet. Users are left with a Switch in
 the System Settings to control this behavior. I would like to see a
 more permanent way to disable the possibility of data leaks.

You can uninstall those components in Ubuntu Software Center. It's not
nearly as easy as flipping the switch in System Settings, but that's
why the switch exists.

 A way for admins to uninstall the capability of the Dash to send
 data onto the internet, irrespective of the switch. This would be
 a specific improvement I would like to see.

Admin control over settings would be useful -- not just for that
function, but many others too. I've sketched how that kind of admin
control might be presented
https://wiki.ubuntu.com/UserAccounts#access, but that design works
only for individual existing accounts. The next step would be a design
for setting defaults for new accounts, and for changing multiple
existing accounts at once.

 #2 is for improved awareness (and hopefully control) of what 
 applications are accessing the internet. A way for users to more 
 easily be aware of what apps are accessing the internet and what
 data they are transmitting. It would be nice to be able to log this
 kind of info. Currently, if the firewall is set to allow outgoing
 on a machine then anything can transmit out on an open port. My
 guess is AppArmor could be used to setup some sort of mechanism for
 users to gain better awareness of applications' internet access
 behavior. Something that integrates with the Unity shell would be
 ideal.
 
 ...

Most of that would be achieved by the Network activity indicator.
https://wiki.ubuntu.com/Networking#phone-indicator

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

iEYEARECAAYFAlMPZbMACgkQ6PUxNfU6ecoTNACdF/eT9V57sS2Y3xWG9+aeXsdx
eYsAmQFm9iO9LGSUbCLRKq15VKAB0ka/
=zuLa
-END PGP SIGNATURE-

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

Re: Ignoring privacy sabotages Ubuntu's best chance for success

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Benjamin Kerensa wrote on 25/02/14 20:35:
 
 On 2/24/14, 3:08 AM, Matthew Paul Thomas wrote: ...
 
 Ubuntu has extensive designs for privacy settings on both PC and 
 phone. https://wiki.ubuntu.com/SecurityAndPrivacySettings As 
 with everything else in Ubuntu, there's always more to do than
 we have time for.
 
 Except the fact that it requires opt-out to sending queries to 
 Canonical and then on to third parties. And that there are still 
 scopes/lenses enabled by default that do not use SSL which leaks
 user queries.

Both of those are problems, but neither is an exception to what I said.

 Protracted but non-specific comparisons to DuckDuckGo aren't that
  useful. Most useful would be for you to implement privacy
 features yourself, or find new contributors to do so. But at a
 minimum, you could be more specific about improvements you'd like
 to see.
 
 You're suggesting that individuals are going to be able to submit 
 patches to improve privacy and that those patches would even be 
 acknowledged?

All patches should be acknowledged, but no, that's not what I said.

 Please explain then why a member of the Ubuntu Tech Committees
 patch has sat without review for two years. 
 https://code.launchpad.net/~kees/libunity/remote-search-none
 
 ...

I have no idea. Seems like a good change to me.

- -- 
mpt

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

iEYEARECAAYFAlMPaqgACgkQ6PUxNfU6ecoyigCfUbqRBVTgSVKXoRpADK42HdYO
qUoAn3ENDpRVkd5YCITCWjENVxdNGCJ6
=ReWo
-END PGP SIGNATURE-

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

Re: Ignoring privacy sabotages Ubuntu's best chance for success

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gerry A. wrote on 21/02/14 16:45:
 
 Ubuntu desktop and phone are great designs but contain a fatal 
 flaw: a failure to foster  utilize what would be one of its 
 strongest assets for gaining market share--Privacy.
 
 ...

Ubuntu has extensive designs for privacy settings on both PC and phone.
https://wiki.ubuntu.com/SecurityAndPrivacySettings As with
everything else in Ubuntu, there's always more to do than we have time
for.

Protracted but non-specific comparisons to DuckDuckGo aren't that
useful. Most useful would be for you to implement privacy features
yourself, or find new contributors to do so. But at a minimum, you
could be more specific about improvements you'd like to see.

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

iEYEARECAAYFAlMLKCIACgkQ6PUxNfU6ecrwZACgqjvU2L8kmxZtVQzxVkI/pkQv
yoQAnRBjWImAbZX1TqNCv6R5sUcja1uc
=bRL6
-END PGP SIGNATURE-

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

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

http://launchpad.net/bugs/76416

- -- 
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: Bug handling in Ubuntu

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Olе Streicher wrote on 21/10/13 16:24:
 ...
 
 When I find a bug specific to Ubuntu, and I do a search for whether
 it is known, I always find lots of old bugs that seem to be never
 read by anyone; just the submitter (and mybe some others that got
 the same problem). Sometimes even a patch exists, or a certain bug
 is fixed in a recent Ubuntu release but the bug still remains
 open.
 
 Two examples:
 
 https://bugs.launchpad.net/gnome-session/+bug/138194 dated from
 2007, still open without any hint that someone is working on it

There's also no hint that it occurs in any version of Ubuntu later
than 11.10! If there was, it would be more interesting to a potential
bug-fixer.

 https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/876661 
 Trivial to fix; a patch was proposed after a year, but was
 (probably?) ignored. Fixed somehow, but the bug is still open.

A Debian bug report was mentioned in the comments, but not linked to
the Ubuntu report (using Also affects distribution). If it had been,
Launchpad would have noticed and displayed that it was fixed in Debian.

 etc. This is quite annoying and also makes the Ubuntu bug database 
 worthless. On Debian, my experience for bug report is quite
 opposite BTW.

Ubuntu has a vastly greater ratio of users to developers than Debian,
so it also has a much greater ratio of bug reporters to developers.

 So I do not understand: it is worth to report a bug? Who is
 looking for them? What is the use of the bug database?
 
 ...

The same as the purpose of any bug database: to help finite developers
make best use of their time.

The more QA volunteers are able to garden bug reports -- attaching
relevant files, marking duplicates, setting Importance, marking old
reports as Incomplete if they're not reproducible in the latest
version, and so on -- the better use developers can make of their time.
https://wiki.ubuntu.com/HelpingWithBugs

- -- 
mpt

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

iEYEARECAAYFAlJqQCQACgkQ6PUxNfU6ecqYbwCdEWpw3/kYiKiPSxTLwDZ0OERO
N/MAnjmtpEGxSEYKXz1226QTVi4vqhKD
=TXNc
-END PGP SIGNATURE-

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

Re: Privacy features in Touch (cyanogenmod)?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matt B. wrote on 03/07/13 15:00:
 ...
 
 I too am concerned about a lot of are you sure dialogs. I think 
 people are just looking for a way to learn/know what apps are 
 connecting to the internet (and why). Like I described how VLC
 asks to connect for downloading album art/info and tells you why it
 would be connecting to the internet. Once the user responds to this
 dialogue there are no more dialogues--ever. The App asks for
 permission to connect to the internet for a specific purpose. If
 the user says No, it would be up to the user to go into settings
 and reset this. The user should not be presented this prompt each
 time the App starts/runs.

With the Ubuntu Touch model, the prompt is shown once ever, not once
each time the app runs. (You shouldn't need to know whether an app is
not running anyway.)

However, an app accessing the Internet is not currently on the list of
things that the OS would prompt about. It could be, but I'm not
confident it would be useful. Such a large proportion of apps use the
Internet, that nefarious traffic would often be hidden alongside
legitimate traffic.

 ...
 
 So I think the most useful OS service is to somehow *give users 
 awareness of App internet connection behavior* so users CAN learn 
 that they need to make a settings adjustment IN THE APP or simply 
 uninstall the App and look for one that isn't so promiscuous with
 the internet. This I think is the privacy/security function of the
 OS that is so important--providing some means of finding out
 which Apps are connecting to the internet, which informs the user
 and allows him/her to decide whether to adjust settings in the App
 or uninstall it.
 
 ...

This is part of the reason I designed the network activity indicator.
https://wiki.ubuntu.com/Networking#phone-indicator

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

iEYEARECAAYFAlHWlNcACgkQ6PUxNfU6ecoLAACguuGva3d9xbvrc+p/f+IL4wB+
h3sAn32qkzhw2eIYLTzUttv3UsQIN3Qz
=1Kbf
-END PGP SIGNATURE-

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

Re: Privacy features in Touch (cyanogenmod)?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dylan McCall wrote on 22/06/13 17:19:
 
 On Sat, Jun 22, 2013 at 7:12 AM, Matthew Paul Thomas
 
 In the next couple of weeks I will design the UI for apps to
 request privileges on Ubuntu Touch.
 
 Yay!

I've now published it, though the UI text still needs a little work.
https://wiki.ubuntu.com/AccountPrivileges#Phone (Other app access
is a dull title.)

 ...
 
 On Ubuntu, an app will request a privilege during runtime. For 
 example, a game might have a find my friends who already play
 this game function, that accesses your contacts. The game would
 work just fine if you don't use this function. But if you do use
 it, Ubuntu would then -- and only then -- ask you if you want to
 grant the app access to your contacts.
 
 I agree this is a good model. Still, I worry about the possibility
 of having a lot of are you sure dialogs in a nicely integrated 
 application.

That's a reasonable concern. But I haven't thought of a case where an
app would needfully request more than one or two privileges at a time.
Have you?

 For the act of adding an online account, I think that should be as 
 simple as choosing an online account from the system Online
 Accounts dialog. The interface will need to clearly communicate
 that in choosing an account you are granting Foo app permission
 to use it, but I don't think there's a reason to have anything else
 on top.

I'm not sure what you mean by the system Online Accounts dialog.

If you mean a dialog that appears mid-screen with the application
still visible in the background, then absolutely. I've charted the
flow. https://wiki.ubuntu.com/OnlineAccounts#phone-access

If you mean the full Online Accounts screen of System Settings, then
that would have some visual consistency between listing accounts
prompted (when an app wants access) vs. unprompted (when browsing
System Settings). However, it would hide the context of the app behind
a full-screen Settings screen. And filtering the list to hide
irrelevant accounts, then adding UI to explain why only a subset of
accounts are being shown, would reduce the visual consistency almost
beyond recognition anyway.

 Similar deal with documents or contacts: there are some odd cases 
 where apps don't want to use the system's Contacts dialog, but I
 think in most cases they should be able to trigger that dialog, and
 have access to specific (selected) contacts granted implicitly.
 MacOS X seems to be doing that nowadays, and Plash (which was an
 intriguing idea that didn't seem to get anywhere) had that sort of
 thing happening for file choosers:
 http://plash.beasts.org/powerbox.html.

It hadn't even occurred to me that an app might want access to a
single contact! I was thinking of the sort of apps that go through all
your contacts, looking for other people who have already registered
with the app. Thanks for raising this.
https://wiki.ubuntu.com/AccountPrivileges?action=diffrev2=12rev1=11

 The other bit I wonder about is how this might affect something
 like the Recent Files list in an application. Do you think that
 sort of thing would work cleanly, or should we be thinking about a 
 replacement? (Or do people even use that?).

I guess the list of recent items would have to be inside the content
picker
https://blueprints.launchpad.net/ubuntu/+spec/client-1305-content-mgmt-picking
and nowhere else. An app couldn't provide its own UI for recent items
that were created in other apps, though it could for items it created
itself. That's what PC apps do anyway.

 One thing that drives me mad with Android's approach is lots of
 apps ask for permanent access to your contacts for a single thing
 that they do, once, ever, but then iOS has driven me mad working in
 the other direction, so I'm really excited to see what you have in
 mind :)
 
 ...

Right. I've mentioned this in the spec: an app might need a privilege
only for an uncommon function that you personally will never use.

Cheers
- -- 
mpt

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

iEYEARECAAYFAlHS+IQACgkQ6PUxNfU6ecqLmwCeMjkwOr4tEAJ8R3TmVzNKuFfE
iVkAoLDIv5e5F2Nes+MP/KJqXvHzcZ5k
=OBQ8
-END PGP SIGNATURE-

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

Re: Privacy features in Touch (cyanogenmod)?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

J Fernyhough wrote on 24/06/13 13:28:
 
 On 24 June 2013 13:13, Marc Deslauriers wrote:
 
 On 13-06-24 08:07 AM, Matthew Paul Thomas wrote:
 
 J Fernyhough wrote on 22/06/13 16:06:
 
 On 22 June 2013 15:12, Matthew Paul Thomas
 m...@canonical.com
 
 On Ubuntu, an app will request a privilege during runtime.
 For example, a game might have a find my friends who
 already play this game function, that accesses your
 contacts. The game would work just fine if you don't use
 this function. But if you do use it, Ubuntu would then --
 and only then -- ask you if you want to grant the app
 access to your contacts.
 ...
 
 This is excellent! One quick feature request: a remember
 this choice checkbox. ;)
 
 I don't understand. Why would Ubuntu forget the choice
 otherwise?
 
 Because granting a permission may depend on the context?
 
 For example, I may want to allow a photo application to use my
 GPS to tag a picture when I'm in some public place, but not when
 I take a picture when I'm at home.

A photo app that triggered an OS prompt to grant access to your
location, after every photo you took, would quickly become intolerable.

More viable would be a setting to use your location unless you are
within X distance of an editable list of locations.

And that setting would likely be more findable -- and would therefore
protect more people -- in the photo app itself, rather than in System
Settings. It would certainly be explained more clearly, because the
photo app would know what it is using the location data for, while the
OS would not. For example, you might want the app to record the
location of every photo for your own reference, but strip it out when
posting the photo online, whether that happened moments or weeks later.

This illustrates my general understanding of the purpose of the
permissions feature. It is primarily for protecting against
overzealous app developers. It is not workable for trying to control
an app's use of data once the app does have access. That can be done
more practically, and more understandably, inside the app itself.

 Granting a permission shouldn't mean I grant it forever, unless
 I decide it should be forever...having both Just this once and 
 Always buttons satisfies my use case.
 
 Marc.

I don't see how those two buttons would satisfy that use case. If you
didn't want to be prompted after every photo you took, each day you
would tap Always after taking your first photo away from home, and
then ... what? Have a separate app that detects when you're returning
home, and reminds you to go into System Settings for your nightly
revocation of location access to the photo app? Sooner or later you'd
forget.

 Exactly this.
 
 Though having buttons would result in four choices: Yes, No,
 Always, Never. Having buttons and a checkbox would be three: Yes,
 No, Remember. I think the SuperUser apps on Android might be a
 good example of how a single request might look? It could get a
 little more complicated if the app requests several permissions at
 once, though.
 
 ...

When requesting access to an online account, the dialog would already
contain up to four controls: a menu if you had multiple accounts of
the selected type, then buttons for Allow, Add Another..., and
Don't Allow.

- -- 
mpt

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

iEYEARECAAYFAlHTJ7sACgkQ6PUxNfU6ecp4PQCfZJXimBom2bQnuv5bibyHhxKz
QKUAoIdlYLHHFMrFSnxwWfmkay+V68XR
=l9O4
-END PGP SIGNATURE-

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

Re: Privacy features in Touch (cyanogenmod)?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

J Fernyhough wrote on 22/06/13 16:06:
 
 On 22 June 2013 15:12, Matthew Paul Thomas m...@canonical.com
 wrote:
 
 On Ubuntu, an app will request a privilege during runtime. For 
 example, a game might have a find my friends who already play
 this game function, that accesses your contacts. The game would
 work just fine if you don't use this function. But if you do use
 it, Ubuntu would then -- and only then -- ask you if you want to
 grant the app access to your contacts.
 ...
 
 This is excellent! One quick feature request: a remember this
 choice checkbox. ;)

I don't understand. Why would Ubuntu forget the choice otherwise?

 Are there any plans to also collect app permissions into one
 place, for example a privacy centre that shows which apps have
 which permissions?
 
 ...

I hadn't thought about that, but that's a good idea. I've already done
a screen for listing which apps have access to your location.
https://wiki.ubuntu.com/SecurityAndPrivacySettings#location Lists
for other privileges could go alongside.

- -- 
mpt

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

iEYEARECAAYFAlHINpsACgkQ6PUxNfU6ecqwBwCfVPP05lP5jDKCTmrtwiPkCiGn
TMUAnAtl2hosqqjDjUWrLeDxj9mEQxYM
=dlf9
-END PGP SIGNATURE-

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

Re: Privacy features in Touch (cyanogenmod)?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Hollocher wrote on 22/06/13 16:31:
 ...
 
 This is poor design. Of all the time you spend with an app, the 
 moment you're about to install it is the moment when you know
 the least about it. So it's the moment when you're least able to
 make informed decisions about granting those privileges.
 ...
 
 On Ubuntu, an app will request a privilege during runtime.
 
 What I see you saying is that by the time I've just begun to use
 the app, I will have a better sense of what the app does, and
 therefor know what privileges to grant.

Not necessarily just begun. For example, you might have been playing
a game for minutes or hours before you encounter the Tweet this high
score button.

 But that isn't the case for me.  Once I've started the app, I'm
 still trying to figure out what it does (even a simple game).  So I
 would just allow all privileges given that I don't know how to make
 a better decision and I at least want to make sure that the app
 works.  I think in general, once I have decided to start installing
 an app, I've also decided that I trust the app.

I'm not interested in encouraging people to decide that they trust an
app before they've even figured out what it does. Criminy.

 So, here is an alternative: before installation.  Have the needed 
 permissions displayed on the installation page, along side the
 ratings and forum discussions and app description.  That way, if
 there is some permission that doesn't make sense, I can go straight
 to the comments section to see any discussion about it. (and make
 permissions something I can search against, that way I can filter
 away unwanted permission takers).

That isn't an alternative; it's the Android model I described in the
first place.

 ...
 
 PS - I think there is a wider issue of incorrectly assuming that 
 giving users finer grained control over privacy will grant greater 
 privacy.  For some users, it has the opposite affect: it
 overwhelms them with difficult questions, leading to yes to all
 types of behavior.

I agree. Prompting before install would effectively require a Yes to
all response, which would in turn encourage app developers to request
privileges they don't need.

- -- 
mpt

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

iEYEARECAAYFAlHIPQ4ACgkQ6PUxNfU6ecqdtwCgo4O8vNwu2xkA9XCrQqKGoz6v
qgEAnjBe1Bpbyuftu6iIxVV9Ch2DAaLb
=URZQ
-END PGP SIGNATURE-

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

Re: Privacy features in Touch (cyanogenmod)?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Benjamin Kerensa wrote on 23/06/13 08:41:
 
 On Jun 22, 2013 7:16 AM, Matthew Paul Thomas m...@canonical.com 
 ...
 
 Ubuntu is an operating system, not a person. Neither you nor I 
 get to decide priorities for Canonical engineers. But anyone is 
 welcome to implement privacy features and propose them for 
 inclusion in Ubuntu.
 
 Canonical Engineers have pretty much ignored the proposal of even 
 one member of the Ubuntu Tech Board in regards to user privacy.
 
 What makes you believe if Canonical ignores a former security team 
 member/current tech board member and the EFF that they will give 
 anyone else's proposal the time of day?

You're being pretty vague, but my best guess is that you're referring
to the default setting for online search in the Dash.

Every week I talk on Mumble with some of my colleagues. When I get
halfway through typing mumble in the Dash, the Amazon results are
ubuntu-calendar all over again. You don't need to lecture me about
what the default setting should be.

That's why I specifically referred to features, not settings, and
implementing them, not just proposing them.

 The sad thing is the community does nearly as much work to produce 
 Ubuntu but has almost no say in its direction or features.
 
 ...

I reject both the premise that Canonical is not part of the
community, and the premise that the EFF is. If the EFF spent even
half as much time contributing to Ubuntu as they've pretended to, we'd
all be better off.

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

iEYEARECAAYFAlHISeQACgkQ6PUxNfU6ecr3TgCfSP6tsZLwMlUaU4ps6b1fM6gx
mzYAn2sy3T5k8CYH0qy0aaVTHZ+SdY9j
=lwB4
-END PGP SIGNATURE-

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

Re: Source packages appropriate by default?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Benjamin Kerensa wrote on 20/05/13 18:02:
 
 On May 20, 2013 8:10 AM, Daniel J Blueman dan...@quora.org ...
 
 For all the general users I install Ubuntu for (including
 servers), it's an utter waste of bandwidth for everyone,
 particularly when automatically checking once a day. This is
 amplified eg in schools without transparent webcaches etc.
 
 Anyone get the same feeling that we should have source packages
 an opt-in?
 
 I think in most parts of the world 4MB is trivial overhead for a
 user. Although perhaps we should consider it since some developing
 nations have limited bandwidth?
 
 ...

With every extra kilobyte required to check for updates, the check
will complete measurably less often. Maybe the notebook lid will be
closed, maybe the connection will time out, or maybe the computer will
be shut down altogether.

(Measurably, but not measuredly: we aren't collecting stats on this.
See http://www.lukew.com/ff/entry.asp?1553 for examples of how even
tiny changes in download times affect Web site success rates.)

When update checks are completed less often, updates are installed
later after they are issued.

So, unnecessary downloads when checking for updates is a security issue.

http://launchpad.net/bugs/74747
https://wiki.ubuntu.com/SoftwareUpdates#Ideas

- -- 
mpt

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

iEYEARECAAYFAlGbQ/QACgkQ6PUxNfU6ecqVsgCdEyP61EWfH42SkFj4Z88Il3u9
MQcAnR5SU/6sBEE7PFuyxl707VH9oSPJ
=nycT
-END PGP SIGNATURE-

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

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
supporthttp://launchpad.net/bugs/812067.

- -- 
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: Ubuntu Manpage Repository need some love

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ma Xiaojun wrote on 29/03/13 17:38:
 
 Man pages for QQ, RR is still not available, despite the fact that
 they are listed.
 
 ...

http://launchpad.net/bugs/1156258

- -- 
mpt

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

iEYEARECAAYFAlFanZgACgkQ6PUxNfU6ecp3bgCdEh61xV4tZp4VnOuY+lp8ajqL
3I8AoKavUaVlfasSNBcnqFB26L0Cdkai
=wUNI
-END PGP SIGNATURE-

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

Re: How is app information in Ubuntu Software Center maintained?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ma Xiaojun wrote on 14/03/13 18:28:
 
 On Thu, Mar 14, 2013 at 7:24 PM, Matthew Paul Thomas
 m...@canonical.com wrote:
 
 As Sergey said, and as hinted at 
 https://wiki.ubuntu.com/SoftwareCenter#bugs, problems with
 search results are either the fault of the individual package, or
 the app-install-data-ubuntu package.
 
 The link is useful! However, I don't want to wait forever for bug
 fixings in app-install-data-ubuntu, for example the synaptic entry
 duplicate bug. Can I take action?
 
 ...

Yes, the same way you would fix any other bug in Ubuntu.
https://wiki.ubuntu.com/Bugs/HowToFix

- -- 
mpt

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

iEYEARECAAYFAlFG6kYACgkQ6PUxNfU6ecqCgwCgkuWa9YcoNPKNgkNtaNzrouhZ
AcQAoIswq+XVm5UKyrpMr+MdJmtUC65A
=+1eM
-END PGP SIGNATURE-

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

Re: How is app information in Ubuntu Software Center maintained?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ma Xiaojun wrote on 09/03/13 07:12:
 ...
 
 For example, Fcitx is an input method framework that I probably
 use sudo apt-get install fcitx to install it. However, in Ubuntu
 Software Center, fcitx-data package, a dependency of fcitx
 packages is advertised as Fcitx app. 
 https://apps.ubuntu.com/cat/search/?q=fcitx
 
 Another example is that Hangul engine of IBus (ibus-hangul) is 
 advertised as IBus Hangul Preferences 
 https://apps.ubuntu.com/cat/applications/ibus-hangul/
 
 ...

As Sergey said, and as hinted at
https://wiki.ubuntu.com/SoftwareCenter#bugs, problems with search
results are either the fault of the individual package, or the
app-install-data-ubuntu package.

Ideally the app-install-data-ubuntu package would be unnecessary, with
Launchpad publishing the correct application metadata for each
package. https://dev.launchpad.net/ArchiveIndex

- -- 
mpt

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

iEYEARECAAYFAlFBs4QACgkQ6PUxNfU6ecpqpgCgtz5AeXhOPVjZq+k0nMIFl8w1
oQwAniM2ApIyd7u/Tey3lIZXhq1a3ZP2
=B2jD
-END PGP SIGNATURE-

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

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.
http://www.youtube.com/watch?v=4FN_S9PoMC8#t=1m24s

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

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

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,
http://developer.ubuntu.com/?s=launcher+badge
http://developer.ubuntu.com/?s=spellchecking
http://developer.ubuntu.com/?s=animation 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: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: 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.
https://wiki.ubuntu.com/ReleaseUpgrades

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

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.
https://wiki.ubuntu.com/SoftwareUpdates#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: 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

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
http://www.ubuntu.com/download/desktop. 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 not listed anywhere except cdimage.ubuntu.com or its successor.

 == 

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

Re: kexec and Grub

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Moser wrote on 10/02/13 23:52:
 ...
 
 https://wiki.ubuntu.com/StartupSettings
 
 I wish I could un-see that second one.  I'm completely baffled as
 to what startup software is (I'd imagine that would be the
 bootloader, kernel, systemd, all systemd/init scripts, and in
 Ubuntu's case X11 as well, along with everything in /bin and /sbin
 and /lib according to how Unix systems are lain out--everything
 required for system start-up belongs there, while everything not
 required for system start-up goes into /usr/)

Yes. https://wiki.ubuntu.com/GracefulFailure But the button's
existence shouldn't be blocked on implementing repair of everything in
the world. So long as no promises are made, fixing 10% of startup
problems is better than fixing 0%. Filesystem location is irrelevant.

 tbh repair systems are a good idea, but they belong in their own 
 place.

If settings exist, people trying to fix problems are going to go into
the settings UI anyway. A better place to offer automated repair of
those settings and related software is unlikely.

 Don't care for Here is a dialog to configure X system aspect.
 Also if your system is broken you can fix this part from here.
 Where is the Troubleshoot my system dialog?
 
 ...

Since neither the startup-specific one, nor the installation-specific
one http://goo.gl/gYbXr have been implemented yet, I don't know why
you'd expect a more general one to exist!

Ubuntu is a brittle system: when anything goes wrong, it's bad at
helping people recover. Someone who isn't a front-end developer, but
wants to help with that problem in general, might start by setting up
an automated system to fuzz-test config files.

- -- 
mpt

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

iEYEARECAAYFAlEbaPcACgkQ6PUxNfU6ecqESgCgmPWG452iGJ/oFC4+EkIfFw05
6mkAoJCucyApHXZo8lWTSEc9ZZCbjAwq
=fKXj
-END PGP SIGNATURE-

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

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. http://launchpad.net/bugs/1072854

- -- 
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 m...@canonical.com 
 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: Crashes from Unity/Xorg continues with 12.10

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas Novin wrote on 23/10/12 19:23:
 ...
 
 On Tue, Oct 23, 2012 at 10:44 AM, Timo Aaltonen
 ...
 On 23.10.2012 09:36, Thomas Novin wrote:
 
 However, after logging in, I didn't get any notification
 that my system had crashed and question about submitting.
 I then read here: https://wiki.ubuntu.com/ErrorTracker
 and changed under Privacy  Diagnostics, Send error
 reports to Canonical. This has no effect though, after
 logging out and then in again I get no question about
 submitting my crash.

This might have been because update-notifier failed to launch at
login. (For hysterical reasons, the code that checks for reportable
errors after login lives in update-notifier.)

 Now I entered this setting again and the option was
 unchecked! It seems that checking that option doesn't
 stick.

That is a bug in the Privacy settings panel, which will be fixed soon.
http://launchpad.net/bugs/993056

 Please advice, how should I handle/report my crashing
 Xorg/Unity..
 
 File a bug with 'apport-bug
 /var/crash/_usr_bin_Xorg.0.crash'.
 ...
 
 IMHO, the automatic bug reporting should really be made easier
 without all those prompts and selections. In Android/Windows there
 is just one question, do you want to submit it, yes/no? That should
 be enough. So this + activated per default on all admin-accounts =
 more submitted bug reports = more stable Ubuntu-releases in the
 long run.
 
 ...

In Ubuntu, error reporting is a single button click, just like on
Android and Windows.

This is a developer mailing list. When Timo suggested using apport-bug
to report a bug instead, he was suggesting an alternative for
developer use because the normal error reporting wasn't working for you.

- -- 
mpt

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

iEYEARECAAYFAlCJTg0ACgkQ6PUxNfU6ecoprQCg0N5da/whbbu6qOyQRFr/6AOg
FvcAn3p6OrY1/XsaqcpByYp3vX+J6Nbz
=SR90
-END PGP SIGNATURE-

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

Re: could you add this feature or discuss it at 13.04 Developer Summit?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nicolas Michel wrote on 17/10/12 07:23:
 
 I think what Brian wants (correct me if not) is an application 
 level firewall. On Windows most antivirus do it : you get a popup 
 when an application try to access something you didn't already 
 allowed to. I think what should be done is an AppArmor graphical 
 frontend (with notifications).

If anyone would like to implement that, here's a design I prepared
earlier. https://wiki.ubuntu.com/Networking#firewall

However, Brian specifically mentioned the logging features of the
application-firewall, not just the firewall itself.

 ...
 
 But honestly, Linux is not Windows Brian. Every application is 
 open-source (except if you installed a propriatary app from the 
 net). It means from a security point of view that everyone can
 read the source code (it he has the skill)  and see what the
 application do exactly.

As Ma pointed out, this is less true as USC sells more proprietary
applications. Even if it was true, though, I expect it would be much
easier to figure out what a program is doing network-wise by running
something like wireshark, than by reading the source code for the
application and all its dependencies.

- -- 
mpt

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

iEYEARECAAYFAlB/uXIACgkQ6PUxNfU6ecqjuQCgpKCoOsdzbFvotkeXoysLAFA7
VAIAnRxRkP9zFdCKsjBmeCKmFVaAW518
=HcXw
-END PGP SIGNATURE-

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

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?
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize

- -- 
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 this new proposal are focused on a 
 specific class of applications that make use of some specific 
 restricted features of the operating system.  The current proposal 
 is geared towards that.  If the real goal though, is to deliver
 all applications this way, I think this proposal is not very
 useful because I don't think it's extensible in the ways it would
 need to be to grow into that.
 
 ...

What else would it need? Be specific.

- -- 
mpt
-BEGIN PGP SIGNATURE

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 m...@canonical.com 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 06/09/12 14:22:
 
 Matthew Paul Thomas m...@canonical.com 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 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 scale to an order of magnitude more applications.

Maybe the current 

Re: The place of the Ubuntu Software Center regarding Steam, Desura and others

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nicolas Michel wrote on 21/08/12 22:52:
 ...
 
 So I thought the best I would want as a user is to search for 
 everything I want to install on my desktop from the Ubuntu Software
 Center. Although I'm not aware of the future plans for the 
 application I think it would be really amazing to have a plugin 
 system on the Ubuntu Software Center to plug external content 
 database to its search engine so we could see the content
 available from Desura, Steam AND Play on Linux (and maybe others).
 These plugins should work (and keep updated their databases) even
 without these applications installed. So the user should be asked
 to install it to be able to install that game or that software.

This would be useful for software developers, too: imagine being able
to access all of Cpan from the Developer Tools  Perl subcategory,
PyPI from the Python subcategory, or RubyGems.org from the Ruby
subcategory.

 ...
 
 Secondly to offer what guys that are coming to our platform are 
 searching for: freedom. You may think it's ironic since we are 
 talking about closed-source softwares but it is not. I'm talking
 of freedom as in freedom of choice. Regarding this topic I think
 the Ubuntu Software Center should really tag clearly what is 
 open-source, closed-source, free of charge and not.

USC already does this. We could perhaps do it more prominently
http://launchpad.net/bugs/715683, and we could definitely be more
specific about the open-source licenses being used.
http://launchpad.net/bugs/435183

 It should also really well highlight who is providing the software:
 Ubuntu, Steam, Desura, others?

We have work to do on this, though each application already links to
the publisher's Web site.

 So we'll have the choice: if I'm searching for the video keyword 
 and I want to use only open-source softwares provided by
 Canonical, I should be able to click on a filter to only see it.
 
 ...

You can already filter on software provided by Canonical, but that's
not the same as filtering on open-source software.
http://launchpad.net/bugs/630730

Cheers
- -- 
mpt

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

iEYEARECAAYFAlA15aYACgkQ6PUxNfU6eco38gCdFIJPvGoAKGAdTFvCs7lLwf95
hAAAnA35Jw09f+qia4JTf99ArNAJBacm
=MBeC
-END PGP SIGNATURE-

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

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 m...@canonical.com 
 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: Potential UI bug: wrong type of dialog upon hibernation notice

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Abhishek Bhatnagar wrote on 01/04/12 01:09:
 ...
 
 As per my attachment, when battery on laptop is critically low, I
 get a dialog informing me that hibernation is imminent, and then 
 gives me two options: Cancel and OK. They both do the same 
 thing - make the dialog go away. Clearly an OK would suffice,
 as Cancel does not make sense in context.
 
 I'm almost sure this happened because someone ended up using the 
 wrong type of dialog, but it probably should be mended.
 
 Should this be filed as a bug?
 
 ...

This is Battery warning popup buttons dont make sense
http://launchpad.net/bugs/883857.

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

iEYEARECAAYFAk94oCAACgkQ6PUxNfU6ecoXEgCgvwJ7w1E1yLvAuc7uazQMyLMP
g4EAoI5Qwc5EO3Yu1IsJAN+3Mq/n0GSr
=5dRk
-END PGP SIGNATURE-

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

Re: Controlling menubar title on Ubuntu 11.10?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Nikos

Nikos Chantziaras wrote on 18/03/12 22:11:
 
 On 14/03/12 18:07, Nikos Chantziaras wrote: ...
 I wrote an application that, at startup, prompts the user for a 
 file (using a standard open file dialog). Ubuntu 11.10 takes 
 the title of that dialog (Choose the file you wish to play)
 and uses it for the rest of the application's session. This is
 wrong of course. The menu bar should display the application's
 name.
 
 Is there a way I can control the title of the menu bar?
 
 ... So I guess it's not possible then.  This is really a
 shortcoming in Ubuntu and doesn't look very well thought out.  But
 I'll have to live with it.

This is straightforwardly a bug in Unity.

I suggest reporting it, and attaching a minimal example application to
the bug report. https://bugs.launchpad.net/unity

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

iEYEARECAAYFAk94nzkACgkQ6PUxNfU6ecpQbgCeM+5LylW2MobITj1A57Si2ILo
gOkAoLOFTyb5l96sCE0Abt8fk4IwOEdY
=5EAw
-END PGP SIGNATURE-

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

Re: Privacy,history and search options

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petko wrote on 19/02/12 11:10:
 
 I like to keep it brief so here it goes :
 
 1. The privacy compartment of the System settings withholds
 settings that rather correlate with the word History in browsers
 (that's not the main argument , but my view on things as a user) .
 As I write I saw that there is a separate History tab (and
 apparently there are other options in the compartment) , so my
 suggestion is to rename Privacy to HistoryPrivacy , because
 now few people would relate what that compartment withholds and
 that makes it less usable .


Yes, logging file and application use is analogous to browser history.
But people are much less familiar with it, so just calling it
History wouldn't explain enough.

http://live.gnome.org/Design/SystemSettings/PrivacyAndSharing?action=AttachFiledo=viewtarget=files-and-applications.png
condenses the history items from three tabs into one, and better
explains why it's a privacy issue.

 2. Add indexing options (2) in the Files tab : a) Index these
 locations (a separate field as the one excluding locations to
 index) b) Recheck indexed locations (a button)
 
 ...


That's conflating logging with indexing. It might be true that the
files you don't want showing up in Recent Files are always (or
nearly always) the same files you don't want returned in search
results, but it would be helpful to think of examples and
counterexamples first.

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

iEYEARECAAYFAk9of2kACgkQ6PUxNfU6ecod8ACeOImXMYKDGvyesTkK7KEGVCgQ
fGQAnj1PpOvhMIZ2EsKhzc9QXjMto1Hp
=f5kk
-END PGP SIGNATURE-

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

Re: can we find a solution to bug #820895 (show Process Name in log files) (imaginative solution/description presented)?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

HSO wrote on 08/02/12 09:02:
 
 2012/2/7, Jordon Bedwell jor...@envygeeks.com:
 
 Stop throwing around privacy like there is some big security flaw
 in Linux, there are tools that do what everyone wants, it seems
 to me that nobody is willing to even look or everybody is fed
 baby food, what is the point of being on Linux if you aren't
 going to use the terminal for what it's there for?  Try searching
 for once.


The vast majority of Linux users never use the terminal, and long may
that continue. Tools are useful only to the extent that people can
work out how use them.

 All you talk about it's planed - some of programed some of in
 progress. Look at: https://wiki.ubuntu.com/Networking


As I said when I linked to that page, none of it is in progress in the
moment. But if anyone would like to volunteer, please get in touch.

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

iEYEARECAAYFAk8zmmIACgkQ6PUxNfU6ecrJrgCfS2eLmv37aQ0oi/dDxZLTVDZw
C8wAoNJsMb372xd4mgzjn8EQXSrlu/rd
=xkyt
-END PGP SIGNATURE-

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

Re: can we find a solution to bug #820895 (show Process Name in log files) (imaginative solution/description presented)?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robbie Williamson wrote on 29/01/12 21:39:
 
 On 01/26/2012 11:12 PM, nick rundy wrote: ...
 
 Just to be clear, I'm not asking that an application-firewall
 (as Jason Todd was speaking of) be created to solve this problem.
 I'm totally fine with a solution that doesn't involve a firewall.
 It's just that an application firewall allows me to solve this
 problem when I use Windows, so it is the only base of reference I
 have to speak to.


I designed an application-based firewall interface to be part of
Ubuntu's networking settings, but no-one has volunteered to implement
it yet. https://wiki.ubuntu.com/Networking#Firewall

 Sounds like nethogs can solve the problem of knowing which
 processes are currently sucking down bandwidth.  As for your
 indicator idea, I think a simple GUI front-end to nethogs would be
 the first step.


indicator-multiload can graph overall network traffic in the menu bar.

 The application could reside with other system apps, and simply be
 fired up when a user wants this information.  An indicator would
 mean nethogs running all the time in the background, unnecessarily 
 consuming resources, imho.  Anyone up for guifying nethogs? :-)
 
 ...


It's even easier than that. System Monitor graphs overall CPU, memory,
and network use in its Resources tab. And it tabulates CPU and
memory use, but *not* network use, per process in its Processes tab.
So all that's missing is a column for network use in that table.

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

iEYEARECAAYFAk8lyOkACgkQ6PUxNfU6ecqepgCgj/G4ElaerifB94GdQrPFxhFF
ahMAn0KGhuaq8XuYRmNdtAWED4VxNkaQ
=v2wI
-END PGP SIGNATURE-

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

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:
https://code.launchpad.net/update-manager

And here's the Aptdaemon reference:
http://packages.python.org/aptdaemon/

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: 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 https://bugzilla.gnome.org/show_bug.cgi?id=641497.

- -- 
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.
https://wiki.ubuntu.com/SoftwareCenter#isv-support

 ... 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. https://wiki.ubuntu.com/Teams

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: 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. https://wiki.ubuntu.com/Teams

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-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Upgrade to 11.10 claims to remove vlc

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sebastian Geiger wrote on 02/08/11 17:18:

 I just upgraded to 11.10. On the upgrade summary I was told that the
 upgrade would later remove the Vlc package as one of 21 packages that
 were about to be removed after the upgrade. Just now the upgrade has
 run through and vlc was not among the packages to be removed anymore.
 Im currious why the upgrade process was telling me that vlc was going
 to be removed and then didnt remove it after the upgrade finished.
...

I had a similar problem: the 11.04 upgrade said that it would remove
openoffice.org-math without installing libreoffice-math, but then did
install libreoffice-math after all. http://launchpad.net/bugs/764817

This kind of bug is hard to reproduce, because reinstalling takes a long
time. But if you have some time for testing, you might try this:

mvo so to reproduce all you need to do is to run apt-clone restore
/var/log/dist-upgrade/apt-clone_system_state.tar.gz
/some/destination/that/will/become/a/chroot
mvo then chroot to that destination and run the upgrade
mvo I admit its a bit time consuiming, but it should allow exact
reproducion of the issue

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

iEYEARECAAYFAk4707wACgkQ6PUxNfU6ecq+ywCdEbz2WUSVD49M9VtgpX8ADTTL
mqUAn0fhgd3gBn6JAoGtJ/agiv4m2Ctf
=I76e
-END PGP SIGNATURE-

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

Re: Fwd: Re: Eventually drop the top-panel?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kai Mast wrote on 27/06/11 22:50:
...
 On 27.06.2011 11:39, Matthew Paul Thomas wrote:

 This would mean that we could drop all the maximize to panel and
 globalmenu-patches.

 I don't know what you mean by maximize to panel. As for the global
 menu, patches for that are heading upstream for Firefox, Thunderbird,
 and LibreOffice 3.4.

 I don't mean the global menu but the way the maximized window and the
 top-panel get merged. Imo this is a sign that the top-panel has no use
 anymore..

I don't understand that logic at all.

  Functionality like the sound menu could also be
  included into the jumplist of the dash...
...
 That would mean things like the time, volume, and battery status
 would be invisible much of the time, and would take up much of the
 launcher when they were visible. It would be the worst of both
 worlds.

 With sound menu I meant the way you can control you music player via 
 indicators. It would be way more straightforward if one could control
 the music player via a jumplist (=right-click-menu).

It would be much less straightforward, for three reasons. First, the
launcher is visible much less often than the launcher is. Second, even
when it is visible, launcher items are sometimes folded off the bottom
of the launcher, while nothing like that ever happens to the sound menu.
And third, a quicklist is accessible only if the music player is running
or is one of your favorites, whereas the sound menu is accessible all
the time.

 Well, you're right some indicators are still needed like the battery
 or network indicator, but this doesn't justify a whole top panel in my
 opinion.

That's possibly true. Phone OSes typically use a whole top panel just
for indicators, but they have much less width to work with.

But it's also irrelevant, because in Ubuntu the menu bar is not used
just for indicators, it is also used for window menus. That would be a
good thing even if there were no indicator menus at all.

  We could move the indicator area into the dash

That would be even worse than moving it into the launcher.

 or even better
 use something like the once proposed wingpanel: 
 http://cdn.omgubuntu.co.uk/wp-content/uploads/2010/12/sipzz.jpg

The wingpanel is mostly a false economy. It relies on you having
something useful to do with the left ~70% -- but not the right ~30% --
of the top row of the screen, which is unlikely.

 My problem with the current situation is that a lot of functionality
 is duplicated. Empathy for example indicates new messages on the dash
 and also in the messaging-indicator...
...

As far as I know, Empathy does not indicate new messages anywhere in the
Dash. It is true that it uses both the launcher and the messaging menu,
and that this is duplication. But the messaging menu aggregates new
messages from multiple applications, and it's not at all obvious how
this could be done in the launcher. Either new Empathy messages would be
shown only in a launcher item that *wasn't* the Empathy one, which would
be bizarre; or they would be shown in both the Empathy launcher item and
the aggregated launcher item, making the duplication much more jarring
than it is with the messaging menu.

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

iEYEARECAAYFAk4K8k0ACgkQ6PUxNfU6ecp0twCeOpadCFQEmtmk9Nk/ExI0JP/U
xqEAoIxtMVovR2oFls/C/fhrwf1+IIp+
=yjPj
-END PGP SIGNATURE-

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

Re: Eventually drop the top-panel?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kai Mast wrote on 25/06/11 12:35:

 Hey Guys,

 I was wondering with adding functionality to the dash like indicating
 progress or a message counters, are there plans to drop the indicator
 menu and with it the whole top panel?

No.

 This would mean that we could drop all the maximize to panel and
 globalmenu-patches.

I don't know what you mean by maximize to panel. As for the global
menu, patches for that are heading upstream for Firefox, Thunderbird,
and LibreOffice 3.4.

 Functionality like the sound menu could also be
 included into the jumplist of the dash...
...

That would mean things like the time, volume, and battery status would
be invisible much of the time, and would take up much of the launcher
when they were visible. It would be the worst of both worlds.

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

iEYEARECAAYFAk4IT8IACgkQ6PUxNfU6ecogwQCePN/PQ2a3ZwNq1hrF4aUBv66T
argAoKVmIFud5tfZsssHZz1bono+Ckjt
=fIjw
-END PGP SIGNATURE-

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

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.
https://code.launchpad.net/~mmcg069/software-center/sc-janitor

- -- 
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.
https://mail.gnome.org/archives/release-team/2010-June/msg00012.html

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