Request For Candidates: Application Review Board

[Michael Vogt]

Hello,

sorry for my late reply, I was away for a couple of days and it took
me a bit to read (and think) through this thread.

On Sat, Aug 14, 2010 at 08:17:24AM +1000, William Grant wrote:
> On Fri, 2010-08-13 at 11:53 -0700, 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.
> 
> There are two main barriers to getting through REVU:
> 
>  1) Low-quality packaging. This restriction cannot be safely eliminated
>     for your proposal -- it exists for a very good reason.
> 
>  2) Lack of manpower. Your proposal is only going to make this worse, by
>     splitting it across two systems with the same purpose.
> 
> > 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.
> 
> Backports.
[..]

Let me start on my thoughs on using backports.

We discussed the use of backports during the UDS session and there was
a consensus that what we want in the longer term is to use backports
for this.

There is a lot of overlap and backports fit the bill pretty
well. However there are some technical issues around the way apt works
and resolves dependencies currently that make it unsuitable to include
backports [1] as it is now into the default sources.list (this is one
of the goals of the PostReleaseApps spec). Those are technical
problems that we will eventually solve, but they are not
trivial. During the discussion it was outlined that fixing apt for
maverick so that backports plus pinning can be used would be a
challange and that as a workaround we should create a new archive
pocket (or a new archive) that can be used to archive the goal.

Essentially what we need in order to use backports is to split
backports into "backports-of-existing-packages" and
"backports-of-packages-not-yet-in-current-release". The later comes
very close to what the PostReleaseApp archive is supposed to do and
can be included into the sources.list by default. This is pretty much
what the PostReleaseApp archive is (modulo the open question of if new
applications always needs to go into the devel release first, but I
guess for cases like "Superbowl 2010" we can be pragmatic and decide
on a case-by-case basis).

I agree (and this was discussed at the session as well) that the
review process is very similar and it does make sense that the
backports team and the AppReviewBoard have a overlap (or are even the
same people). Because the skill set required is very similar.

So from my POV the PostReleaseApps repository is essentially a subset
of backport (stuff that is not yet in the stable release) that we did
not put into backport because of technical issues. I think we need
high standards for this repository (just like for backports) and good
reviews. Even if we label it "independent" we feature it in
software-center so we need to make sure it is a good experience for
our users. I also think it's filling a important role. This was
outlined by others in the thread already (better than I could do
it). But the landscape is changing and we need to adapt (without
compromising our standards). 

James Westby raised the idea of "proto-packages" (we discssed about it
a couple of times before). I think the idea is pretty neat. Deb
packages are great for what we use them - to build a distribution. But
for a lot of "simple" apps we don't actually need the power that they
have (just the opposite, I consider it harmful to be able to have
maintainer scripts that run as root and can alter the system state in
any way they want because it makes auditing much harder and it kills
our ability to rollback, completly remove a package). So I can see
room for packages that do not require root, do not need installing (in
the traditional way) and that are easier to sandbox. This is of course
a big technical (and UI) challenge.

Cheers,
 Michael

[1] The problem is essentially that not-automatic sources or pinned
down sources will not be considered for dependency resolution, so that
a application "A" in a not-automatic source that depends on "B" in a
not-automatic source will not be installable unless apt is explicitely
told to install both A and B (for normal sources it will figure that
out automatically). This is half a bug and half a feature, but not
entirely trivial to fix.