Request For Candidates: Application Review Board

[Scott Kitterman]

On Wednesday, August 18, 2010 10:59:59 pm Allison Randal wrote:
> On 08/18/2010 02:40 PM, Scott Kitterman wrote:
> > 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.
> 
> Yep, the team who started Quickly focused on simple, local apps, and it
> was the right place to start. But, the sharing component was embedded in
> the idea from the beginning. Scratch wouldn't be a success without both
> pillars: easy to create, easy to share. To really do that well, creation
> and sharing need to be tightly integrated. In Scratch, there's a "Share"
> button right in the IDE. Click the button, enter a title and
> description, and hey-presto your app is distributed. We're a long way
> off from that, but it's an inspiration for future potential.
> 
> It could be anyone's problem, but the Ubuntu project is in a unique
> position to make it happen, and one of the core principles at the heart
> of Ubuntu is taking disruptive, visionary, game-changing steps that pave
> the way to the future.

Certainly sharing is important for the opportunistic programmer use case, just 
not public sharing to all users of Ubuntu.  I'm fine with being disruptive and 
visionary, let's just not pretend we knew all along this is what we were 
doing.  It's great to expand the vision as it matures, but we don't need 
revisionist history to feel OK with it.

> > 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.
> 
> I'll flip that around and say that this new apps process is a result of
> redefining the original problem (lightweight app sharing), in the
> context of an already working solution to a different problem
> (Debian-esque package distribution). With refinement over time we'll be
> truer to the original idea.

At this point I think it provides an alternate process to achieve a goal that 
was already achievable, but is not significantly lighter weight and so that, if 
implemented post-Maverick release, it is likely to achieve is confusion and 
dilution of resources.  It was a good try, but I don't think it got anywhere 
useful.  

I think that is because as long as the deliverable is a Debian package that 
runs as root it's not possible to get significantly lighter weight than what we 
already are.  I certainly didn't understand this when we discussed this at 
UDS.  I think developing the process was a useful learning experience, but I 
think carrying it forward and attempting to actually deliver Debian packages 
this way will be counter productive.

> > 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.
> 
> Completely agreed, "if we are delivering Debian packages". That is, if
> the whole purpose of this new process was to improve the Debian
> packaging process, we should do that by improving the Debian packaging
> process. Okay, that's a tautology. :)
> 
> But, while it made sense to use (very simple, often automatically
> generated) Debian packages for this phase to take advantage of existing
> infrastructure, there are also many ways in which Debian packaging is a
> less-than-ideal fit for lightweight app sharing. This is really
> something new and different, a fork in the road. Not an "either/or"
> fork, but a "both/and" fork. That is, we continue with improvements to
> backports, etc. for the Debian packaging system which is (and will
> continue to be) the core of the Ubuntu family of distributions AND we
> explore the possibilities for lightweight app sharing.

Agreed.  I just think we need to have some understanding of what these new 
lighter weight apps will be and how they will be delivered before we can 
usefully understand what process and structure we need (and I'll say again, 
without the current effort having been done, I wouldn't have understood that 
and so I think it was useful).

> > 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.
> 
> The naming is confusing, we'll need to do some work on that as a community.
> 
> And it would be wonderful to have the sandbox in place from the start.
> But, at UDS-M the discussion all centered on whether there was any way
> at all a lightweight app sharing process could be crafted that would fit
> with community policy, satisfy the requirements for security and quality
> control, and be approved by the technical leadership. We were still in
> the early "feasibility" stage, a long way from writing specifications
> for advanced features that require substantial development.

Yes.  I think the answer now is pretty clearly that no, it's not possible to 
have a noticeably light weight process that meets all these requirements as 
long as we are delivering Debian packages.

> And there's a bit of a chicken-and-egg problem getting volunteers (or
> paid developers or the managers who allocate their time) to invest in a
> new idea. You need to show it's possible, and then get enough working to
> show that it's usable and desirable. It's a whole lot easier to get
> people involved in fixing a seedling, than in bootstrapping something
> completely new.

I think we've done the developmental process experiment for Maverick and we 
ought to set that aside and do a developmental technology experiment for 
Natty.  The results of these two efforts should show us where to go for a 
useful synthesis in N+1 and something really exciting to end users in N+2 
(presumably the next LTS).

> > 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.
> 
> I expect that at UDS-N we'll have at least one blueprint on sandboxing.
> But I also wouldn't want to hold back the whole idea for one feature
> (even an incredibly important feature) when we can phase it in gradually
> as it's developed. As we offer stronger sandboxing, we can lighten the
> process for sandboxed applications, lower the demands on the application
> reviewers, and even broaden the pool of people who can participate in
> application review. (A modestly sandboxed application could be reviewed
> by any reasonably skilled Python developer, while reviewing heavily
> sandboxed applications could be a task for new developers. More on that
> in reply to Robert.)

This is where I really disagree.  My conclusion based on where we are now is 
that until we have something usefully safer than a Debian Package to deliver 
new apps into we won't have a usefully lighter process to get things through 
in an efficient and effective manner, so we might as well not pretend we do and 
cause confusion and dilution of effort.

...

Scott K