Implementing new apps post release

There are two separate blueprints for this feature:

• How to do it technically (here)
• what policies about when we allow apps (link needed)

Scope

The scope of the feature is to deliver new application to end users with minimal risk of regression. To minimize the risk of regression all new new application are reviewed by a team of reviewers to ensure the packaging is ok and to do checks of the source (similar to what is done for a MIR). Given that the ubuntu-backports project has a similar goal and scope (with a slightly different focus) it makes sense to work closely together or even have the same reviewer team for both.

To prevent breaking existing functionality only new applications (leaf-node apps) are allowed into the repository, no backports of system libraries, drivers, kernels etc. If the later is required the backports component is more suitable.

Stability is key because we want this feature to be enabled by default so that new applications can show up in software-center.

Implementation

The scope of this feature is similar to the backports project. There is a important difference however. Backports can have anything backported (including system libs and existing packages), not just leaf-node applications.

There are different way of implementing this feature:

• as a part of the backports pocket
• as a PPA
• as a new pocket alongside backports (e.g. maverick-new-apps)

Using backports

Just using the backports pocket is a simple way to enable this feature. It would mean that we need to enable -backports for all users (to satisfy the goal that they show up in software-center). To do this we need to use the "NotAutomatic: yes" flag for -backports or use apt pinning to ensure that for existing packages the version in -backports is not choosen by default. This is a useful for backports as well and a goal in the longer term.

Before this can be done we need to solve the following problems:

• The apt resolver picks the candidate version at cache-build time. If A depends on A' (and A' is in -backports and also in the main repository), apt will pick A' as the candidate. Trying to install A will fail if it needs the version of A' from backports. This needs fixing in the resolver or by using the aptitude resolver (and making it available for python-apt)
• There is no GUI that makes it easy to pick selected new install packages from backports. If a users wants to install A' (both available in backports and main)he needs to use the commandline or synaptic and its select-version feature (packages with multiple versions are not highlighted in any way in the synaptic UI currently though).
• There is no GUI in update-manager to select if a update should come from -updates or -backports if its available in both.

Using a PPA

Using a PPA is conceptually similar to using a new pocket. The advantage is that it does not need changes to soyuz. The disadvantage is that the PPA is not mirrored (and goes down when launchpad goes down for maintenance?) and the packages do not get a bugpage in LP automatically (like they do when a pocket is used). If that is not a concern a PPA is fine.

Using a new pocket

Using a new pocket eliminates most of the code changes needed outlined in the "Using backports" section (no need to modify update-manager, apt or synaptic to get better support for multiple versions).

All we need is some UI in software-center to highlight applications coming from the "-new-apps" pocket. For the other package management tools apps would automatically show up as "new" (in synaptic or aptitude). So they would get a certain level of exposure even from people who do not use software-center.

Enabling this new pocket by default is very little risk of regression as it will only get new packages. The worst that can happen (if the maintainer scripts are not broken and we check for file conflicts) is that the app will not install or work.

A new pocket needs communication with the mirror community to ensure they know about it. The ACL for uploading into -new-apps would be similar -backports.

Handling of updates

The policy of updates for -new-apps needs to be discussed. There are some options:

• no updates at all
• updates into new-apps-proposed
• updates directly into new-apps
• updates go into a PPA first and we ask people to test before
  • pushing into new-apps

Option 3+4 sounds like a reasonable solution if we require a review process for each update and if a test install/upgrade is required as part of the review. The risk of regression is relatively low as only a single app can break (unless maintainer scripts go bad). The extra testing it gets from the PPA (option 4) is a bonus.

UI changes

The exact design will done by mpt. There needs to be some UI that highlights new applications so that we show the user that the content stays fresh. It can be a new category, a special place in the main category screen or a side panel.

The goal is to generate excitement, similar to ratings and reviews

QA

Good QA is key. Use the tools we have to ensure it:

• file conflicts checker
• pick ideas from the NEW processing
• maintainer scrips are the most critical part
  • - we currently depend heavily on maintainer scripts, eg update icon cache - debhelper-auto-generated maintainer scripts are lower risk than manual maintainer scripts to deal with - NO diverts, update-alternative in maintainer scripts (too risky) - in general: as simple as possible, complicated is a reason for rejection
• to avoid file conflicts/maintainer scripts entirely something that does not involve deb packages would need to be evaluated (in the future)

Open questions

• how to store the metadata (icons, screenshot, mimetypes) for the
  • new apps (server side repository metadata)
• can screenshots.ubuntu.com used for the screenshots?
• Should new-apps have a similar policy as backports to require that
  • the new apps go into the development release as well?
• what should update-manager do on release upgrades when the new app
  • is no longer available in the new distro release? Remove as cruft?
• what build dependencies should the new pocket use (main,
  • main+updates?)

Risks

• the scope of just leaf node apps with no system libs may be too
  • limited, few interessting apps
• People may prefer using new-apps over putting apps in the
  • repository because it gives them more exposure in software-center

Notes

Workflow

• Requirements for Launchpad UI:
  • We can optionally just use the current process for devel.
  • Users identifying a package in their PPA for software centre.
  • A review process for a team to review all those proposals (or, use the
    • current sync process - needs to work via API and allow syncing from devel release or PPA).
  • On successful review, automatic copy to the decided destination (main
    • archive, certain pocket- backports or new 'coolapps', potential fallback would be a ppa owned by ubuntu-devs)
  • Automatic email to reviewers, and user depending on outcome of review.

POR

• bigjools says we can probably add a new pocket for coolapps
• ACLs, workflow for backports
  • clone the backports ACLs process for cool apps, maybe not the same team
  • no sources changes require for a backport, there is a script that runs that copies from the PPA into backports