[RFC] apturl repository whitelist application process

[Alexander Sack]

On Thu, Feb 12, 2009 at 05:10:07PM -0500, Brian Thomason wrote:
>    First off, thanks to both of you for getting this done.  It's something
>    we've wanted on the ISV side of things for a while now.
> 
>      ==== Formal Prerequisites ====
>       * In order to ensure transparency and to facilitate monitoring of
>       quality and the state of the repository, a launchpad project must be
>       maintained for the package. Each source package should have it's own
>       repository where appropriate.
> 
>    This would be a troublesome requirement for someone like google who
>    maintains all of their apps in the same repo.

we appended the "where appropriate", which means that there might be
exceptions. It's just that we believe that its easier for both the
reviewers and the repository maintainers to provide dedicated apt
sources lines for each application they provide.

If they don't they cannot upload a new package to their (already
whitelisted) repository before getting a review on the package.


>     
> 
>       * 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.
> 
>    What if the vendor prefers to handle all bugs through their own bug
>    tracker?
>     

I addressed that in my other reply to Scott..

> 
>       * Package namespace for the name should start with a unique prefix
>       and not conflict
> 
>    Must we require a prefix when there is no chance of a natural collision?
>    For instance, if google wants to ship google earth and the package name is
>    google-earth, can we waive the prefix requirement?
>     
> 

I would think that with "google-" we already have a prefix we could
use for that. It might be a bit special case as we already have google-
prefixed packages in the archive, but in general i don't see a problem
to use the vendor name for prefixing vendor hosted packages.


>       * Identify third party repository by custom package/source control
>       field
>       * add XB(S)-ThirdParty-RepoURL to the package that is uniq to
>       identify where the master repo is
>       * Identify right place to file bugs by custom package/source control
>       field
>       * add XB(S)-ThirdParty-BugFileUrl to the package that points to the
>       bug report page (LP)
> 
>    These seem a little onerous too.  If the control file already provides a
>    website for the product, that should seemingly sufice as they are already
>    required to have the bug tacker info prominently displayed
>    there...?

Having the used bug database and the used repository in the control
file gives easy access for reviewers to all the most basic information
to get started.

Also later we could use the bug file url to automatically direct users
to that url if we encounter crash or something.

>     
> 
>      However, if necessary, the repository may actually be removed from the
>      users' sources lists. This may be necessary if there are severe
>      problems on the repository such as data lose errors, security
>      problems, repository maintainer is not cooperating. The repository can
>      not reapply for at least 1 year for inclusion again
> 
>    I don't think we should make the 1 year a steadfast rule, or at least
>    shorten it dramatically.

I agree, we should address that.


 - Alexander