Request For Candidates: Application Review Board

[Scott Kitterman]

On Monday, August 16, 2010 09:11:20 pm Allison Randal wrote:
> To take a step back to the broader vision (and answer several parts of
> this thread at the same time):
> 
> This all started at UDS a couple of years ago, in a meeting about how to
> attract more application developers to Ubuntu (and Linux in general). I
> offered Scratch (scratch.mit.edu) as an example of how easy it can be to
> develop and distribute applications, and of the kind of community energy
> you can build up when you lower the barriers to entry. Three days later,
> Quickly (https://wiki.ubuntu.com/Quickly) was born.[1] Quickly has done
> a fantastic job of solving the "develop" side of the equation, making
> sane default choices, common boilerplate starting points, and reusable
> widgets for developers. The "PostReleaseApps" process is the next
> logical step, looking at the "distribute" side of the equation.

Quickly, when it was developed was described as being aimed at the 
opportunistic developer who needed something relatively simple to solve a 
local need.  The distribute side of the equation for these kinds of developers 
is a local problem and not one for Ubuntu.  I think that targeting these kinds 
of developers was and is important, but that is orthogonal to the post release 
apps process, so I think post release apps process is a logical next step only 
after you've redefined the problem, but in the end, I don't think it actually 
gets us there at all.

> Since that first meeting, the iPhone/iPad App Store and Android
> Marketplace have clearly shown that there's demand for revolutionary new
> ways of distributing lightweight apps. User expectations are shifting,
> and so are developer expectations. Now those same iPhone apps are
> running on the iPad, and it's only a matter of time before the Apple
> desktop is dominated by the same (or similar) App Store. It remains to
> be seen if Microsoft will catch the wave, but I've had conversations
> with others who see the writing on the wall for Windows too, and want a
> slice of the pie.

No one (that I recall) has argued against the idea of making it easier to get 
new apps to users.  The argument (at least mine) has been that inventing an 
entire new infrastructure and set of processes rather than building on what we 
have right now is not the best way to go about it if we are delivering Debian 
packages.  If we want to radically simplify the process to achieve this goal, 
then we need to change in infrastructure to support applications.  The thing 
IOS and Android have that we don't is a sandbox structure to limit the risks 
of installing untrusted/lightly reviewed applications.

> What we have now in the PostReleaseApps process is a very conservative
> toe-test of the waters. Several comments in this thread are around the
> general theme of "How is this any different/better than REVU?" Well, it
> really isn't yet. There are important security and quality reasons why
> our current packaging process is what it is. It's a solid, reliable
> process and we won't diverge far from that in the first round. But
> there's great potential in the future. For example, Android and Scratch
> can be so completely open to new app distribution because the code runs
> in a tightly controlled sandbox, with guarantees that the worst a bad
> app can do is crash itself (think "PyPy sandbox" but better).

I'd like to see the foundation work for providing a similarly safe environment 
(sandbox) precede  this new process it rather than follow.  I also think that 
labeling this the Ubuntu process for getting applications to users post 
release is very confusing for people who are interested in more traditional 
packages that can already be delivered to users via backports.  We need a 
different term for these sandboxed applications that can be quickly delivered 
in a lightweight process.  Users will still want traditional packages and so 
we need to clearly distinguish between the old and the new in technical 
structure, language, and process.  Doing the process first puts the cart before 
the horse.  It is confusing at best.

> There's been great feedback in this thread on things like the
> distinction between the current distribution process and this new
> process (not enough distinction yet), on the review process (still too
> heavyweight), demands on our limited developer resources (still too
> high), the developer process for building the packages (still too
> heavyweight), handling dependencies and porting to later releases (still
> needs architect/design/implementation work).

I'm still not clear that absent a true sandbox where it is 'safe' to install 
applications that are not fully trusted, there's any point to this at all.  I 
think there are active risks associated with this process of dilution of 
talent and end user confusion.  I would prefer it if people would take this 
feedback and defer deployment of anything until there is something that will 
usefully distinguish these new [whatever we are going to call them] 
applications from applications delivered as Debian packages.

> The design and development of this idea will happen on this list and on
> #ubuntu-devel. (There's little risk of overwhelming the general traffic
> here, and a great risk of missing good feedback if we created new
> channels.) Thanks for your help shaping it.

There is definitely a problem that needs solving, so I'm interested to help 
work on it.

Scott K