brainstorming for UDS-N - Application Developers

[Scott Kitterman]

On Tuesday, October 05, 2010 09:19:41 am Matthew Paul Thomas wrote:
> 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=up
> dates-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.

So it's better to accept a library update when you don't have time to 
troubleshoot?  I don't think this distinction is terribly helpful.  Open Office 
may be a leaf application, but if I've got a presentation I have to get 
finished to give to a customer tomorrow, it's a lot more mission critical to me 
at the moment than any number of core libraries.

What's needed is to communicate to the users the benefit associated with the 
change.  For example, most SRU fixes are only important to the set of people 
having the problem that the SRU addresses, for anyone else there is no benefit 
to upgrading at a time when it might be inconvenient.

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

Why it's different, why it's a good thing it's different, or why drawing 
analogies from things that are substantially different has little relevance?

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

But it can't be done by fiat.  We didn't achieve the packaging system we have 
now accident and it will take good engineering work to get to something that 
is both simpler and functional.  I don't know of anyone that defends the 
current complexity of packaging as a good thing, what we lack is tools to to 
get there.  Additional theorizing that it should be easier, doesn't really 
help.

Some of the work that Barry Warsaw has done on stdeb and Python packages is a 
good example of what needs to be done to make our environment more welcoming 
to upstream developers.

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

Debian/changelog isn't meant for non-technical end users.  If you want 
something that is, we need something different.  The packaging changelog serves 
it's own useful purpose.  The fact that it doesn't also serve this purpose is 
not a deficiency in debian/changelog.  That's out of scope for it.

OTOH, it's difficult enough for technical people to write text that is sensible 
to non-technical users.  Please don't insist I learn some new markup language 
too.

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

It's not a technically well founded step.  We should be doing the engineering 
of something that is suitable for a lightweight review and approval process 
before we deploy one.  The current App Review Process if more like shuffling the 
deck chairs on the Titanic.

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

Right, but once again, let's not get the cart before the horse.  We need the 
capacity and tools to deal with the expanded data set before we can make use 
of it.

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

That's the one.  It covers changes to the apt resolver to deal with 
dependencies in a non-automatic repository, changes to make -backports not 
automatic, and U/I to present multiple versions of packages to users sensibly 
(once backports is not automatic, they'd need to be able to pick if they want 
the stable release one or the new one from backports).

None of these changes are particularly difficult, but the lack of them makes it 
difficult for many users to run with backports on, since they get all the 
backports and not just the ones they want.

It isn't a lot of effort, but until it's done, it's difficult to really push 
backports as a solution for getting packages into the current release (I also 
see this as not the same as what extras are focused on - it could easily 
encompass what extras is doing, but it covers much more (potentially any leaf 
application and not just new rapid development efforts)).

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

I agree that there are advantages to diversity and competition, but Android 
Marketplace isn't a very positive example of this in my experience (I've no 
experience with iPhone, so no opinion on their app selection).

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

Right, but Android Marketplace is primarily a source for external 
applications.  In a Linux distribution that isn't the case.  I relatively 
routinely run into bugs or mailing list messages  where people are complaining 
about PPA packages, so I already see this as a problem.  Third party 
applications (or changes to existing packages) are already too closely 
identified with Ubuntu.

Scott K