Proposing a New App Developer Upload Process

[Scott Kitterman]

On Thursday, September 06, 2012 05:05:41 AM Emmet Hikory wrote:
> Scott Kitterman wrote:
> > On Thursday, September 06, 2012 04:14:40 AM Emmet Hikory wrote:
> > >     To avoid conflicts of interest, I suggest that agreeing that the
> > > 
> > > content of the repository to be populated through MyApps is to be
> > > treated
> > > as part of Ubuntu is a prerequisite: otherwise there is too much
> > > potential
> > > for those Ubuntu Developers who have decided to entirely ignore the
> > > presence of a third-party external repository called "extras" to
> > > complain that their upload is unreasonably blocked, and no sensible
> > > conflict resolution path due to the lack of a common authority other
> > > than sabdfl.
> > 
> > That's not the only way to solve the procedural problem.  It's been
> > established that the Ubuntu technical board has the authority to set
> > policy
> > for the Canonical Partner archive.  I have assumed that they do for extras
> > as well.  If they don't, that can be fixed without redefining what is
> > part of Ubuntu and what is external to it but related (for those
> > unfamiliar, Partner is served from a different archive
> > (archive.canonical.com) and not formally part of Ubuntu).
> 
>     Ah, if the partner precedent is extensible also to extras (and it may
> well be given that the ARB has often referred to the Tech Board to take
> decisions), then that also satisfies the prerequisite, so that in the event
> of conflict, there is a means to request external resolution (either from
> the Tech Board, or, if this becomes a significant burden, from some
> delegated authority), which we might reasonably expect to be binding for
> Ubuntu Developers.
> 
>     Independently of the conflict resolution model, I still don't understand
> why we would need to consider such a collection of software "external",
> beyond the historical precedent: is there a reason we want to prevent an
> interested Ubuntu Developer from fixing a bug in one of these packages? Do
> we feel that having two clearly documented competing different processes
> for the inclusion of software will help our users to be able to run the
> software they prefer?  Do we want to prevent upstream developers from being
> able to maintain their software as part of Ubuntu?  Should flavours be
> restricted from seeding packages submitted by the original developers
> unless they are willing to override the upstream submission?

This alternate submission model will have it's own tools, processes and 
procedures.  I doubt that all Ubuntu developers will be sufficiently aware of 
these that the ability to upload into the alternate process should be allowed 
by default.

It does raise an interesting question about the need for a group of extras 
'gardeners' (in the same sense MOTU are Ubuntu archive 'gardeners').  Outside 
the ARB we don't have such a thing now, AFAIK, and we might want to get such a 
group if there are people interested.

>     Yes, there are trust issues, especially if the submission is the first
> time we encounter some developer, but these can be handled by limiting
> what their software is permitted to do, without necessarily resorting to
> banishing the software from Ubuntu, and doing so in such a way that also
> delivers it to users to that later inclusion in Ubuntu may require even
> more discussion and coordination than has historically been required,
> rather than just a shift between different parts of Ubuntu as the
> necessary trust is established.

I think use of a container based approach would make this easier since MyApps 
packages would be operating as if they were part of the standard system and so 
it should be just a matter of adding breaks/replaces/transitional package the 
MyApps pacakgename and uploading.

> > FWIW, I think it's entirely appropriate for Ubuntu developers to not be
> > overly worried about third party repositories.  Any solution that
> > requires them to be concerned will drive Ubuntu to a forked namespace
> > with Debian and that will be a fundamental change in the way the
> > distribution works that I don't think we want.
> 
>     My apologies if I created this impression: while I agree that we should
> impose no requirement that Ubuntu Developers be aware of the content of
> arbitrary third-party repositories, I believe it is in our interest to both
> have a clear means in place to resolve potential conflicts resulting from
> those third-party repositories we have agreed to present to users as
> potential defaults, and to follow namespace claims for what we might expect
> to be promoted as "the way" to request that software be made available to
> our users by the developers of that software.  Of course, if the inclusion
> requirements for such a third-party repository are such that it prevents
> any namespace claims, then there is no need to be concerned, but from the
> discussion so far, I don't believe we will reach this during the quantal
> cycle.

I don't think any substantial part of the new process will be implemented in 
this cycle or the next.  It will take time, so I think it's critical that the 
investment in infrastructure be based on a design that has potential to scale 
to the target level (as I've mentioned elsewhere, I have my doubts about the 
wisdom of the goal, but that's a separate issue).  I think the current 
proposal fails in this regard.  I think that any system that's going to scale 
over 100K packages is going to have to have private namespaces for these 
extention packages (that have no requirement [and in fact it's preferable if 
they don't] to share filename space).  

There is more than one way to solve this problem.  The current method, 
/opt/com.ubuntu.extras/$packagename solves this, but creates other issues, as 
has been discussed.  Containers, like lxc might be another approach.  I don't 
have a strong opinion on the implementation, but the overall requirement to 
have separation I think is critical for both scalability and security.

Scott K