[RFC] apturl repository whitelist application process

[Scott Ritchie]

Alexander Sack wrote:
> (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?
> 

As long as the actual bug reports end up in our bugzilla we'll be happy.
 If we need to install the launchpad bugzilla plugin that would probably
be acceptable as well.

>>> ==== 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.
> 

The example I had in mind was where Ubuntu has chosen to keep a stable
package but upstream is offering betas for user testing, which is a
fairly standard third party repository use case.  Ubuntu avoids the
possible regressions, but early adopters can still get a reasonable package.

>>> === 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.
> 

Is there any infrastructure for moving the actual repository?  I could
desire to move my repo to a launchpad ppa and it would be nice if we
could push out some sort of update pointing to the new server.

>>> === 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?
> 

It's a series of packages designed for people who don't live in caves :)

https://help.ubuntu.com/community/Medibuntu

What's important here is that they, by necessity, replace some of the
Ubuntu packages.  For instance, they provide a replacement version of
mplayer capable of viewing DVDs; requiring them to instead package a
separate version that sat alongside our own stripped mplayer would be
counterproductive.

Thanks,
Scott Ritchie