[RFC] apturl repository whitelist application process

[Alexander Sack]

(resending to list ... forgot to hit the proper reply button :))

On Thu, Feb 12, 2009 at 01:35:04PM -0800, Scott Ritchie wrote:
> Alexander Sack wrote:
> > Hi all,
> > 
> > One of the topics on the jaunty agenda was to come up with a process
> > document that defines how third party repositories can apply for
> > apturl whitelisting and how we can ensure that such repositories are
> > of high maintenance quality. Based on various discussions we drafted an
> > initial policy-like draft, which you can find below. Please comment.
> > 
> 
> >  * In order to assure that packages in third party repositories are
> >  being properly maintained, each landing page that offers an apturl
> >  link must also contain a prominent link for reporting bugs in the
> >  related launchpad project.
> > 
> 
> At Wine, we would much rather they report bugs straight to our own bug
> tracker, as only I look at the Launchpad bugs.  I imagine other projects
> may be the same way.

The requirement to ask for a launchpad bug tracker had two main
goals

 1. reduce the work imposed on the review team; having different bug
 trackers for different packages could make this harder than necessary

 2. allow ubuntu developers to escalate bugs to third party
 repository maintainers, without knowing details.

So while its probably a bit cumbersome for 1, I see your concern and
think that having a launchpad project with the (public) bug tracker
details set up should be good enough. Would that work?

> 
> > ==== Use-Case Prerequisites ====
> >  * Only packages where inclusion in the appropriate Ubuntu repository
> >  is not feasible for some technical or licensing reason will be
> >  considered.
> 
> Do beta packages meet this description?

You cannot really say that without considering individual cases
imo. Some software might be more useful to have in beta form than
others.

Some might even be of higher quality than final versions of other
applications.

> 
> > 
> > === Repository Quality Requirements ===
> > Users have a right to expect the same level of quality and stability
> > from packages installed via apturl as applications installed from
> > other methods. Therefore, third party repositories for stable Ubuntu
> > release _must_ deliver a stable user-experience comparable to those of
> > ubuntu standards.
> > 
> 
> Apparently not then.  Apparently the goal is for a Wine PPA to take
> over, which is fine I guess now that they're signed.  The only thing I
> really lose from all this is that I can no longer collect web statistics
> on package downloads and such -- will Launchpad be providing any such
> feature?

What I think is important here is the stability of the packaging
itself. So if your repository has a good track record to provide
stable packages that have carefully selected package versions and that
don't get refactored frequently, I don't think this should be a
general blocker.

We don't place any restrictions on where you host your
repository. While PPA works (now that its signed) it seems to be ok
to have your own repository as long as its signed et al. What matters
is how that repository is maintained and its track record.

> 
> > === Package Requirements ===
> >  * Package namespace for the name should start with a unique prefix
> >  and not conflict
> >    with any existing name on the system
> >  * File system layout of the package should be to install to /opt -
> >  unless there is a good reason for individual files to be shipped
> >  elsewhere.
> 
> Some repos will want to replace system packages (eg medibuntu)...this
> seems incompatible with these requirements.


I am not sure what medibuntu does. Is that a derivate?

 - Alexander