brainstorming for UDS-N - Application Developers

[Evan Dandrea]

> On Tuesday, September 28, 2010 05:31:26 pm Rick Spencer wrote:
> > We want to empower, engage and harness application developers to develop
> > on and for Ubuntu. These sessions cover the many elements in achieving
> > that goal.
> >
> > What's high on your list for this area?
> >
> > There are some existing conversations and threads that people should
> > feel free to comment on in addition to any new areas:
> > * Changes to the implementation of the New Apps on stable releases
> > (suggestions have included changing the system to use backports as an
> > avenue onto a stable release, for example).
> > * Changes to the Application Review Board process (including, for
> > example, eliminating it and replacing it with a streamlined backports
> > process).
> > * Enhancement, changes to tools such as Glade, Gedit, etc...
> > * Anything about Quickly and/or Quickly Widgets, including new
> > templates, improvements to the existing template, new widgets, etc...
> > * Information Architecture for application developers, including a
> > developers manual, etc...
>
> If we are going to meet the goal of really streamlining the process for
> developers to get their applications in front of users, then we need to change
> what it is that is delivering the application.  I don't think that a
> traditional Debian package is going to be able to support a truly lightweight
> process.

Thank you.  This is something I've been thinking about for quite a while and
it's comforting to know that I'm not alone in what entrenched minds must find to
be very radical thinking.

I think our current architecture for packaging and delivery is built on top of
some misconceptions.  Namely, that we can solve the problem of buggy software
getting into Ubuntu by fixing bugs in applications on behalf of developers,
that packaging needs to be complex, and that we should be and ultimately need
to be doing the legwork to package these applications ourselves.

Buggy software is going to get into Ubuntu no matter what we do, /but that's
okay/.  Equally, if we patch these applications ourselves, what kind of message
is that sending to developers about our trust of them, and whose responsibility
broken software is?

If we have to package the applications ourselves because it requires years of
experience and understanding of an inordinate amount of complexity, what does
that say about our package management system?

Instead of handicapping developers based on these misconceptions, we need to
free them to deploy applications and make choices on their own, then deal with
the repercussions themselves.  We need to empower our users to make the best
decisions on what applications they should use without having to think hard
about their options.  So lets introduce some new metrics in Ubuntu Software
Center, and lets make it so that they are applied to the sorting automatically.
We can start by lowering the page rank of applications that not only have low
ratings or low download counts, but also have high bug counts, that have high
crash reports, and that have a large time delta between bugs and their fixes.

Lets further build on this to create a tight feedback loop between developers
and users.

We need to make it so that developers can quickly deploy an application that
then appears in Ubuntu Software Center for anyone on that release of Ubuntu,
regardless of where we our in our own cycle.  We need to make it so that users
can very quickly provide valuable feedback on these applications *directly* to
developers in the form of bug reports, crash reports, ratings, and reviews.

These bug and crash reports should be presented in Ubuntu through a common
desktop interface, but ultimately hit a web API on the backend.  Let developers
choose what bug tracker and project management system they want to use, be it
Launchpad or something else.  The important thing is that we send bugs straight
to them rather than expect users or an overburdened QA team to ensure that bugs
filed in Ubuntu get back to the developers.  No longer will bugs fall into the
void.  No longer will there be a separation between a packaging bug and a bug in
the application.  A bug in the software you use is a bug in the software you
use; it doesn't matter where it ultimately manifests.

This application deployment system I describe should at no point block on a
human being from the Ubuntu project like our existing systems, both the regular
archive and -extras, do.  These quite simply cannot scale.  Instead, lets
create an automatic system that takes an application submission, runs its test
suite, does some static analysis, and conducts any other sanity checks we can
think of before letting it through to the archive.  If any of these tests fail,
it simply rejects the application back to the developer.  Let them worry about
fixing it.  Let them take complete ownership of their work.

This system wont catch everything and we shouldn't ever operate on the false
hope that it will.  All it's meant to do is filter out the very worst that we
can catch, and leave the rest up to the users to try and report back on.

We should also give the developers flexibility in the way in which they stage
out these deployments.  We should allow them to offer an application to say, 5%
of the Ubuntu audience, wait for feedback, and if it doesn't have any grave bug
reports coming in, push it to the remaining 95%.

I believe that in order to do this properly, we need to massively simplify our
packaging model.  Anything that makes a package non-atomic (hello maintainer
scripts) should be thrown out.  Anything that adds needless complexity, equally
so.  Packaging needs to be the least important part of the puzzle, not the most
difficult, and most certainly not at the core of our own development efforts.

We need to make it our goal that any software developer should be able to
package their application without difficulty and without causing harm to the
system.

Most importantly, unlike -extras, we shouldn't restrict this to just packages
that do not already exist in Ubuntu.  To tell developers that we will not let
them use this system just because we packaged their software first is
ludicrous.