Request For Candidates: Application Review Board

[Scott Kitterman]

On Monday, August 09, 2010 05:53:09 pm Elliot Murphy wrote:
> On Mon, Aug 9, 2010 at 5:34 PM, Scott Kitterman <ubuntu at kitterman.com> 
wrote:
> > Yes, so you achieve the same result by getting the package into the
> > development release and then doing an immediate backport.  The only
> > barrier to this is lack of people to review new packages, so I don't see
> > how creating some other process to have people do work that is working
> > around the lack of people to do the current process is going to help.
> 
> This is a fair point, and staffing the review team will be crucial to
> the success of this new process. You are also right that adding this
> parallel system is not likely to increase the amount of labor
> available to the existing REVU and backports processes.

The pool of qualified team members is finite and unless Canonical is hiring to 
expand the pool (or the amount of time community developers can afford to 
invest in Ubuntu development), then this new review board will come at the 
expense of other work.  If "not likely to increase" is a euphemism for 
"decrease", then I agree.

> However, I believe the new process will be easier to market to
> application developers that we definitely need to be winning over, and
> the flowchart (subjectively, when I imagine explaining this to an app
> developer that I'm trying to win over) feels less clunky than going
> into the dev release and then immediately into backports. It also
> prevents the app developer from needing to run the development release
> of Ubuntu, instead they can stay on a stable foundation and focus
> exclusively on building the app without worrying about the platform
> shifting beneath their feet from day to day. I love running the dev
> version of Ubuntu, but I've seen it stress out upstream app developers
> over and over when they just want to focus on building their app
> without thinking about libraries or desktop changing underneath them.

Most community distro developers don't run the development release for most of 
the development cycle.  There's certainly no need for application developers 
to do so.  Any release specific testing that needs to be done can be done in a 
vm or chroot.

BTW, the new process is silent on how these applications eventually make it 
into Ubuntu?  Once the next release hits they won't be in the current release 
anymore because we skipped the part where we get the packages into the 
development release.

> Also, there is a 2-3 month period each release cycle where we should
> not put new packages into the development release (from feature freeze
> through to when the new archive opens), and this new process avoids
> putting app developers in a holding pattern or stall if they show up
> during that freeze.

The primary reason for most of that freeze is that archive administrators do 
not have the spare time to do lots of New processing late in the release 
cycle.  Except for the last couple of weeks, if there is time for proper 
reviews, it doesn't risk the release to add new packages.  If there are 
resources available to review packages for this new pocket, then there should 
be no problem putting them in the development release and backporting instead.

I've seen packages hit the development release and backports on the same day.  
I still don't see any valid rationale for this.  It's just going to distract 
from the existing processes and make the lack of manpower to do them worse.

Scott K