Proposing a New App Developer Upload Process

[Allison Randal]

On 09/04/2012 10:02 AM, Emmet Hikory wrote:
> 
>     The above notwithstanding, I'm all in favour of being able to safely add
> new or frequently changing packages with policy-compliant filenames to Ubuntu,
> both during the life of a release and as part of future releases.  I'm just
> concerned that our attempts to work around some of the problems we have had
> with such systems in the past may lead to us creating new systems that closely
> parallel older systems without addressing the issues that caused the prior
> systems to no longer be considered ideal for future progress.  Given my
> experience with cleanup after the pull of all the random apt repos, and work
> with REVU, I feel fairly strongly that we ought create an implementation that
> closely integrates with exsting Debian tools and avoids as many potential
> sources of conflict as possible.  If we are to have a high-throughput mostly
> automated mechanism for new packages to be added, we need to be sure that we
> have not created too many bottlenecks relying on human discussion, whether
> this be too high a reviewer overhead, a need to coordinate yet another
> namespace conflict resolution forum, or anything else.
> 
>     Based on this belief, while we might have any arbitrary process by which
> applications are submitted for review, the only reason I can see for treating
> the packages as any different than any other unseeded package is either some
> technical limitation or if we somehow felt that we had different levels of
> trust for packages in one place or another (as reflected by our trust in the
> reviewers, presumably).  The more effort we spend to create a "special" and
> "different" class of applications, the greater the chance we have created
> a division in the self-perceived identities of our various developers where
> none need exist.
> 
>     Of course, this may not be considered safe (see all the sandboxing
> discussion in the spec), but I believe we'd do better to help those who
> are developing applications follow a model that generates software that
> we would be happy to welcome as regular system software than to encourage
> those who might need greater system access to find ways to work around
> whatever limitations we might attempt to put in place.  If we can use
> the same front-end to the application developers for *both* types of
> applications, we reduce both confusion and dissention, and likely find
> that our implementation need have fewer loopholes, as there is a means
> to easily move software from the restricted facility to a more regular
> facility, with full filesytem access, no network restrictions, etc.
> which we may use whenever we find a package that might otherwise require
> an extension to the facilities available.

Well said!

Here's my perspective, in short form:

- Extras is PPU + Backports + training wheels.

- Extras is a place to experiment with how the training wheels should
work, without disrupting the main archives.

- Eventually Extras should go away, once we've extracted the best value
from the experiment.

The proposal that started this thread is rather lengthy, and contains
2-3 years worth of work on tooling. It's a valuable seed for discussion,
but really too much to digest all at once. I'd like to focus on what to
do in the next Ubuntu release cycle. Partly because each cycle *is* a
fresh experiment for Extras. What we've learned in previous cycles has
radically changed the plan already, and is sure to do so in the future.
And partly because we may not agree right now on the ultimate future
(some won't agree with me that Extras should go away, others won't agree
with me that it should stick around for a little while longer), but I'm
confident that we *can* agree on what the immediate next steps should be.

These are what I consider to be the most crucial immediate questions:

- Should we change Extras operation so it's less like REVU (approving
each package) and more like PPU (approving a particular developer for a
particular package name)?

- Should the DMB be made responsible for approving those Extras PPU rights?

- Should we remove the /opt install requirement?

- Should we start developing tooling for more automated package
checking/sandboxing?

My vote is: Yes, make it more like a PPU. I see advantages to recruiting
the DMB for approvals, but they may not want the extra work. No, we
shouldn't remove the /opt requirement, at least not yet. Maybe later
when we have more advanced tools. And heck yeah!, we should start
working on the tools. We can keep doing manual reviews until the tools
are good enough that we trust them. (And will always make the tools kick
back to manual review for anything they can't handle.)


My ideal future looks something like: Debian and Ubuntu co-habiting on
DebExpo (either on mentors.debian.net, or two sites with federated
data), with a slick UI, and fantastic integrated tools for automated
package checks. But, there's a lot of development work between here and
there, I can't just snap my fingers and make it happen tomorrow.

Allison