Request For Candidates: Application Review Board

[Scott Kitterman]

On Friday, August 13, 2010 02:53:19 pm Rick Spencer wrote:
> On Fri, 2010-08-13 at 13:05 -0500, Ted Gould wrote:
> > On Mon, 2010-08-09 at 14:25 -0400, Scott Kitterman wrote:
> > > On Thursday, August 05, 2010 08:42:58 pm Jono Bacon wrote:
> > > > As such, if you are an
> > > > application developer and want to get your app in the software
> > > > center, the process is probably too complex and involved.
> > > 
> > > In what way is this new process simpler and less involved?
> 
> It is significantly less involved. As an application developer, if you
> can get your application into a PPA, you can then get it into Software
> Center. If you use Quickly to build your app, it's easy to get your app
> into a PPA.
> 
> These differences may seem slight to people who are already highly
> skilled packages and who are motu or core-dev. But we must understand
> that the barrier to entry in terms of technical skills to contribute to
> Ubuntu as a platform is much much higher than the barrier of entry to
> create a web app or deliver an app to the iPhone for example.
> 
> You can use this process to deliver it to the *current release* that you
> developed it for, you don't have to wait 6+ months for the next release
> to roll around, and you don't have to master the skills for packaging
> and delivering into universe.

That's nonsense.  With backports you can have stuff in the development release 
and in backports on the same day.

I will ask again, what packaging requirements for the archive don't apply to 
this initiative?  If we are imposing unnecessary requirements on packages we 
should just remove them in general.  If we aren't changing the packaging 
requirements then there's no difference in the barrier to entry associated with 
packaging.

I'm not at all familiar with iPhone, but I know that in Android add-on 
applications are significantly sand boxed from the rest of the system, so the 
risks of "bad" applications are much different than in Ubuntu.  That says to me 
that a different barrier to entry is not necessarily a flaw.

> > Not to speak for Jono, but I was thinking that this was less about
> > getting into the archives and more about choosing "Featured
> > Applications" and the default applications on the CD.  The problem in
> > the past is that it's been basically the Desktop Team manager that has
> > chosen.  Where as the goal was to have a community process for choosing
> > between things like F-Spot and Shotwell for instance.
> 
> No, it's not about that. This is about releasing new application onto a
> stable release. This was discussed in considerable depth before, during,
> and after UDS.
> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-opportu
> nistic-apps-stable-release
> 
> Jono is asking for volunteers for this:
> https://blueprints.edge.launchpad.net/ubuntu/+spec/community-m-post-release
> -app-process
> 
> As you can see, significant effort has already been invested to making
> this work, and that work is nearing completion.

This is also significantly different than what I was involved discussing at UDS.  
The UDS discussion centered on leveraging our existing infrastructure (via a 
slightly improved backports process and structure) and not creating an 
entirely alternate infrastructure that will drain resources away from Ubuntu 
development.

> This is probably the most exciting feature to me in Maverick. It will
> make Ubuntu a relevant target platform for a whole new batch of
> application developers that will be inspired to write FOSS applications.

OK.  What's the opportunity cost?

It would have taken far less resources than have been invested in creating 
this alternate infrastructure to fix backports to be usable for this and work 
better for it's existing uses (this has been proposed since Jaunty):

https://blueprints.launchpad.net/ubuntu/+spec/foundations-maverick-backports-
notautomatic

The same people who you are targeting for being involved in the app review 
board are (I think) the same people who are already in short supply for 
reviewing applications that use the existing process:

http://revu.ubuntuwire.com/

We have people who have been patiently waiting, trying to get their apps (or 
apps they are interested in) into Ubuntu for multiple release cycles.  So we 
are now going to siphon people away from this (and other community development 
work) to get throw away apps into the current release.  I don't see the sense 
in this.

> Note that these application developers we are thinking about are a user
> who is different in kind then the developers who build Ubuntu itself. If
> you are currently writing web pages or iPhone applications, then you may
> want to write an application to run on Ubuntu, even if you have not the
> time, ability, or interest to contribute to Ubuntu as a platform.
> Starting in Maverick, you will be able to do so.

Except that isn't true.  They still need to get their app packaged, so the 
requirements are identical to what they are now (unless some aspects of policy 
are waived for this category - if so, I think everyone ought to understand 
what is waived and we ought to consider just removing such requirements for 
everything).

I don't think this provides anything that doesn't currently exist except a 
shortcut around some processes that are under resourced.  Under resourcing 
them even more isn't a good long term answer.

> This is awesome.

This definitely something.  That's not the word I would pick.

Scott K