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
> 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
>> 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
> Some might even be of higher quality than final versions of other
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
> 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
>> 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
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
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel