Request For Candidates: Application Review Board

[Scott Kitterman]

On Friday, August 13, 2010 07:29:55 pm William Grant wrote:
> On Fri, 2010-08-13 at 16:06 -0700, Rick Spencer wrote:
> > On Sat, 2010-08-14 at 08:17 +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.
> > 
> > For the record, this isn't "my" proposal per se. I had a vision for what
> > I wanted to happen, and the repository to use and the process to vet
> > applications were implementation details that actually qualified people
> > set ou.
> > 
> > So, for your #1, I think the idea is that smaller and simpler apps are
> > easy to package.
> 
> How does that refute my point? If the packaging is simple, it's simple
> to get through REVU.
> 
> > For your #2, it seems that the pressure for more reviewers will come if
> > there are more apps to be reviewed. I'm not clear on why the apps being
> > bound for one repository or another will significantly change that
> > equation, but I'll take your word for it.
> 
> Splitting manpower between two review sites is pointless and not a
> positive thing.
> 
> > In any case, it's clear from the feedback on this thread that we badly
> > need to expand our capacity for reviewing in the the community. I know
> > of a few other projects that are facing similar backlogs.
> > 
> > > > 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.
> > 
> > I don't actually recall why backports wasn't chosen for the repository.
> > I remember that it was discussed in some detail, though.
> 
> Others have said that it's unsuitable because backports need to be in
> the development release first. But, as also raised elsewhere in the
> thread, this needs be handled somehow anyway. And with the "simpler
> apps" to which you refer, this should be trivial.
> 
> > > > > 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-o
> > > > pportunistic-apps-stable-release
> > > 
> > > Backports is also for releasing new applications onto a stable release.
> > > A few improvements there would make them just about equivalent to your
> > > proposal, with a lot less effort.
> > > 
> > > > Jono is asking for volunteers for this:
> > > > https://blueprints.edge.launchpad.net/ubuntu/+spec/community-m-post-r
> > > > elease-app-process
> > > > 
> > > > As you can see, significant effort has already been invested to
> > > > making this work, and that work is nearing completion.
> > > > 
> > > > 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.
> > > > 
> > > > 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.
> > > 
> > > How does this change things? Packaging quality still has to be
> > > excellent, and the quality of packaging is the main thing that REVU
> > > checks.
> > 
> > Because smaller and simpler apps can be built with tools like Quickly
> > that make packaging much easier. Being able to actually package my apps
> > and get them into a PPA was one of the my primary motivators for even
> > starting that project.
> > 
> > > > This is awesome.
> > > 
> > > Awesome? Perhaps. Able to be achieved better through backports? Almost
> > > certainly.
> > 
> > Again, I don't recall why backports was ultimately not chosen as the
> > repository.
> 
> Perhaps this should be considered before introducing new archives and
> processes that duplicate others that have existed for several years.

It was considered.  We discussed it at UDS and I thought that was the 
direction this was going to go.  This was not the plan Canonical showed up 
with at UDS and I would be interested to know why they switched back.

Scott K