Request For Candidates: Application Review Board

[Scott Kitterman]

On Friday, August 13, 2010 05:30:01 pm Mackenzie Morgan wrote:
> On Fri, Aug 13, 2010 at 4:34 PM, Scott Kitterman <ubuntu at kitterman.com> 
wrote:
> > On Friday, August 13, 2010 02:53:19 pm Rick Spencer wrote:
> >> 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 see one difference in barrier to entry.  To get it into a
> development release, the author is going to (at some point) have to be
> running our development release with toolchains and dependencies
> changing under their feet every day and bugs galore.  Developing for a
> stable release takes less headache and involves less "oh gosh but what
> if it doesn't work tomorrow??"
> 
> It's not a packaging barrier to entry, but it is a developmental one.

We routinely don't rebuild packages that don't change in a new release unless 
they are affected by an ABI change in a library that requires a rebuild.  Sane 
tool sets (I know not all of them are sane, but what can you do - anyone using 
insane tool sets is eventually going to get burned) should rarely have to make 
sourceful changes to move to a newer release.  If this isn't true, then we 
need to start rebuilding the entire archive every release.

I agree that being required to run the development release might be a 
substantial barrier, but I don't think it's one that actually exists.  With 
the rise of easy and ubiquitous VM technology, I think even this isn't much of 
a barrier.  

Testing if your package will build on the development release does not require 
any capabilities beyond what's needed for this process (except being able to 
spell the name of the development release correctly in debian/changelog).

It may well be that there are perceived barriers to entry, but I don't think 
they are real to any significant degree.

Scott K