brainstorming for UDS-N - Application Developers

[Krzysztof Klimonda]

On Fri, 2010-10-01 at 17:56 +0100, Evan Dandrea wrote:
> > 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?

We patch software ourselves not because we believe we can fix bugs on
our own - we do it so our users are not exposed to potential new bugs in
the newer version of the software. The message we send to upstream
developers is that we care about their software (after all we have to
care to prepare and test patches ourselves), but our users come first. I
don't think there are that many upstream developers who don't like it -
that's how most big distribution works. Some of them are even helping us
locate bugs worth fixing in our releases.

What we should work on is getting more Ubuntu developers to interact
with upstream - not only forwarding bugs to their BTS, packaging new
versions etc. but also make sure that upstream know who they are, that
they can be their point of contact for Ubuntu-related questions and
problems (and people are already working on it - see
https://wiki.ubuntu.com/Upstream/Adopt ).

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

Packaging requires experience because of the way software is installed,
updated and interacts with other software. It requires understanding of
the system. Adding a detailed changelog makes it easier for our users to
make sure what can they do with their software. detailed dependencies
make it easy to make transitions etc.

Also, packaging a simple desktop application is really easy this days.
Making it even easier wouldn't really help us to provide a better
software to our users.

> 
> Instead of handicapping developers based on these misconceptions, we need to
> free them to deploy applications and make choices on their own, 

Okay, but what about our users? Are they supposed to deal with errors
made by developers?

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

Isn't it what would reviews and voting for application achieve?  I don't
think that the application that crashes often enough for it to be
important or have other severe bugs is going to get a lot of positive
reviews and a good score.

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

What does it really mean? Our users already have contact informations
for the software they use, upstream developers have an unlimited access
to Launchpad (they can easily get accepted to the ~ubuntu-bugcontrol and
triage bugs on LP). We are already providing an infrastructure for
nightly builds. What else should be done? Probably worth discussing on
the UDS.

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

The can add software to the current development release and request a
backport to previous releases.

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

No, we create a distribution for our users not as a place for developers
to dump their software to. Unit tests, static analysis, any sanity
checks we can think of can be either bypassed or plain wrong. Your idea
could work if all applications were sandboxed (i.e. Android model) but
not in Ubuntu.

There is a scaling issue and the burden on both maintainers and QA team
is big but removing this burden by removing them from the process is not
going to make Ubuntu a better distribution (for our users [1]).

[1] I use "for our users" quite a lot - that's because what is good for
developers (or even for us) is not always good for the users of our
distribution - for example developers want to push their new software to
as many people as possible in as little time as possible but, on the
other hand, not all users are interested in the newest and greatest
stuff.

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

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.

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

Now, the idea sounds pretty nice but I'm not sure it would work well.
Leaving aside the question how to do that I'm concerned that it would
make community support harder and making people feel bad that they
"don't have an access" to the newer software while their friends do.
Things like this are done - beta tests etc. but not at this level. It
would feel like we, as Ubuntu, are limiting our users.

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

Isn't it a goal for Quickly? We can obviously work on making it easier
for developers to prepare a preliminary packaging but it still has to be
checked by someone familiar with Ubuntu and Debian.

Upstream developers shouldn't have to understand various distribution,
their packaging methods, policies they have in place. But that means
that there have to be people who understand those things (because there
is a reason for them) who can either prepare packaging or proofread and
fix a packaging made by developers.

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

I believe it would be much better to work closely with upstream projects
(open source and, in fhe future, with closed projects) to make then
understand what the "Linux Distribution" is about, how does it differ
from Mac OS X and Windows and why is it, at least in our opinion, a
better alternative.

We should make it easier to package software but not by making packaging
easier but by providing resources for developers to read, by providing
channels (mailing lists, irc channels) they can use to ask for help.

Best Regards,
 KK

-- 
Sent from Ubuntu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101001/55ec17c1/attachment-0001.pgp