brainstorming for UDS-N - Application Developers

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote on 04/10/10 17:43:
>
> On Monday, October 04, 2010 10:31:36 am Matthew Paul Thomas wrote:
>...
>> The usual consequence of the current approach is that people have to
>> suffer a bug for up to six months after the application developer has
>> released a fixed version.
>
> They equally often manage to avoid dealing with regressions associated
> with  new versions of the software.  It annoys me to no end to get an
> update on my Android that then breaks something and I get three updates
> in four days getting stuff that was working before back to working.
> Currently it's pretty safe to apply updates in Ubuntu and I don't (on
> desktops) spend a lot of time considering the situation.  Stability of
> a release is a feature not a bug.

Sure. We'd need to make more of a distinction between updates to the
core system, and updates to applications. So Ubuntu developers would be
accountable for stability of the core system, and application developers
would be accountable for the stability of their applications.

For example, in Natty we'll be doing work that makes it easier to
visually distinguish core updates from application updates.
<https://wiki.ubuntu.com/SoftwareUpdates?action=AttachFile&do=get&target=updates-list.jpg>
That alone would make it much easier for someone to (for example)
postpone an application update to a weekend when they have time to
troubleshoot any problems. In future, it might even be possible for them
to roll back to the previous version.

>...
>> Every general-purpose operating system has gone through a stage where
>> the primary publisher of software for it was the OS vendor themselves.
>> Every popular general-purpose operating system quickly outgrew that
>> stage.
>
> The Linux distribution paradigm is different than other operating
> systems.  I don't think the analogy is relevant.

I'm interested to know why.

>...
> We have fourteen year old MOTU also.  Packaging should not require
> understanding of the system and software should write itself.  Both are
> interesting theories, but will take some work to accomplish.  We can't
> just banish packaging by fiat.  It will take some work to really
> develop a system that, given certain standardized choices and
> constraints, makes packaging trivial.

Yes, it will be a challenge.

>...
>> Do you think that more than one in a thousand users of the average
>> Ubuntu application have ever looked at its changelog?
>
> On Android Marketplace, the information about updates is displayed
> prominently and is (I think) very important.  What we currently ship is
> not the most user friendly information, but in a world where
> application updates are not mediated by the distribution development
> process, users will need to be more aware of what's changing in their
> software, not less.

Absolutely. I would love it if changelogs were as beautifully presented
as this, for example:
<http://sparkle.andymatuschak.org/>
<http://launchpad.net/sparkle>

That would be two useful things for Ubuntu and Debian developers to
collaborate on. First, agreeing on a way to write or generate
human-readable changelog language (for example "This update fixes a
security problem where an attacker could run unauthorized code",
separately from the text that says "SECURITY UPDATE: integer overflow in
strfmon() might lead to arbitrary code execution"). And second, agreeing
on a lightweight markup language for changelog formatting, so that
changelogs are still readable by traditional tools, but look nicer when
presented graphically.
<http://en.wikipedia.org/wiki/Lightweight_markup_language>

>...
>>> Okay, but what about our users? Are they supposed to deal with errors
>>> made by developers?
>>
>> That's between the developers and their users. Our job is to make that
>> interaction easier.
>
> Yes, but it needs to be done in a reasoned, technically well founded
> way. Appointing a new board and declaring a new world order isn't
> enough.

That's true. The App Review Process is a very small step.

>...
>> That's true. But submitting a crash report, to a real crash database
>> (instead of abusing a login-required bug tracker for it, as we do
>> now), would take a tiny fraction of the effort required to submit a
>> rating and review. Therefore there would be many more crash reports
>> than ratings and reviews. So we could show better rankings by using
>> both.
>
> Except we turn crash reporting off post-release so we don't get
> inundated with reports.

If we used a real crash database, we wouldn't need to do that. For
example, Mozilla's developers continue collecting crash reports
post-release.
<http://crash-stats.mozilla.com/products/Firefox/versions/3.6.9>

>...
>>> The can add software to the current development release and request a
>>> backport to previous releases.
>>
>> Which, as Jorge said, they don't.
>
> The current design doesn't suite this terribly well.  The amount of
> work to get to something that does is small, but has sat on the TODO
> low priority pile for at least a couple of years.

Is there a specification for this work? The only relevant blueprint I
see is one where you're asking for backport updates to be non-automatic.
<http://launchpad.net/ubuntu/+spec/foundations-n-backports-notautomatic>

>...
>> In the past four years, not one but two operating systems have each,
>> starting from zero, accumulated more than 20 *times* as many
>> applications as Ubuntu has. What we are doing is not working. It's
>> time to try something else.
>
> I fundamentally think this is wrong.  As a user I really don't need
> MORE applications.  I need applications that are better, more stable,
> faster.  The new use case is rare.  Just going for volume isn't the
> right answer and the lack of a certain volume isn't indicative of a
> problem.

I'm not suggesting that "just" going for volume is the answer. But it is
part of the answer. For example, when my mother switched from Windows,
one basic requirement was a genealogy application as good as, or better
than, the one she had been using in Windows. Ubuntu has only one
genealogy application, Gramps. Mac OS X has a dozen. That, by itself,
made it much more likely that one of them would be suitable for her.

(Other parts of the answer are tools, guidelines, and reference
materials that make it easy to develop good applications, and ratings
and reviews that allow non-geek feedback and informal competition
between applications.)

>...
>>>                                                               Your
>>> idea could work if all applications were sandboxed (i.e. Android
>>> model) but not in Ubuntu.
>>
>> Ubuntu Software Center, for example, has unit tests without being
>> sandboxed.
>
> So?  Software Center is maintained and developed by trusted developers
> and so doesn't require sandboxing.  If you want to get beyond the
> standard distribution model of software deployment, then you are going
> to need some technical measures to isolate untrusted applications from
> other applications, user data, and system elements they are not
> authorized to use.

Sure. Sandboxing is desirable for restricting applications from
untrusted developers. But Krzysztof was saying that it was also
necessary for automated testing, which I don't think is true.

>...
>>> When broken software reaches users it's already too late. By
>>> publishing something in *.ubuntu.com "namespace" we take
>>> responsibility for it and users are going to complain to us.
>>
>> That's not credible. Neither Ubuntu Software Center nor Update Manager
>> reveal the domain name of the software they install, even for people
>> who know what a "namespace" is.
>
> If it's installed through the "Ubuntu Software Center" of course the
> attach the Ubuntu brand to the quality of the experience.  I'm not sure
> how you could imagine it otherwise.
>...

I imagine it by real-world counterexample. If an individual application
installed from the App Store or from the Android Marketplace is crap,
people don't generally assign responsibility to Apple or to Google, they
assign responsibility to the people who wrote the application. If *most*
of even the top-rated applications were crap, that would be a different
story.

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

iEYEARECAAYFAkyrJe0ACgkQ6PUxNfU6ecrdkQCgqAy7knbZTjK9YmA7/1jZog6r
hJ8AoNBevmezSRXmF32fFli0ymqs+PGr
=g4dG
-----END PGP SIGNATURE-----