Implementation of delivering apps post-release

Registered by Rick Spencer on 2010-04-20

Revisit this discussion for Natty, is the desired implementation for Natty?
We've split this into 2 blueprints.
1. Implementation planning (this blueprint)
2. Process and Policy - now here:

When a developer writes a new application, how do they get it to Ubuntu users today? Their options are:
1. create a PPA for each release that you want to support, and hope end users find the PPA.
2. develop on the current development release early enough to get the application into universe for that release, and get the application into Universe.

#1 means that your app is not discoverable, but #2 means that only users who upgrade can get access to your application.

In this blueprint I propose that we change the game a bit, by making it possible to deliver new applications to end users through software-center in the stable release, starting with Maverick.

Blueprint information

Sebastien Bacher
Michael Vogt
Needs approval
Gary Lasker
Series goal:
Milestone target:
Started by
Gary Lasker on 2010-11-04
Completed by
Gary Lasker on 2010-11-04


[rickspencer3] Doesn't seem to be any software-center or other work to do here for Natty, so untargeting (2010-11-04)
Work Items:
create new archive DONE
implement sync from app-review-board PPA to archive: DONE
verify apt-xapian-index plugin code using the test package(s) in the app-review-board PPA (dependent on fix for bug #613468 that is scheduled for deployment on next LP update on Sep. 9th): DONE
make a wiki page describing how to add metadata support in a package destined for the new-apps archive (include screenshot details) - DONE
support screenshots for apps in DONE
[mvo] add to default sources.list (lp:~mvo/apt-setup/extras-ubuntu-repo): DONE
[mvo] add matcher template to pyhton-apt/software-properties: DONE

Work items for maverick-alpha-2:
create app-review-board (Application Review Board) team in Launchpad: DONE
create app-review-board PPA: DONE
[mpt] design presentation of new items: DONE
[mvo] create prototype implementation in software center for display of new apps in the app-review-board PPA: DONE
file RT request for creation of the archive and sync from app-review-board PPA: DONE

Work items for maverick-alpha-3:
[mvo] add code to update-software-center/update-apt-xapian-index that reads /var/lib/apt/lists to process the plugin code (else, can't show icons): DONE
[mvo] add code to detect new packages in and mark them as new in the database: DONE
[mvo] add code that indexes new apps in the archive: DONE
implement UI in software center for display of new apps: DONE
add a node to the left navigation pane to display items in the new apps archive (currently the app-review-board PPA): DONE
[mvo] implement ability to limit the number of new items to appear in the list: DONE
[mvo] define additional metadata in debian/control (XB-AppName, XB-Icon, XB-Screenshot-Url, XB-Category) needed in debian/control: DONE
implement apt-xapian-index plugin to index the additional metadata: DONE
verify apt-xapian-index plugin code correctly indexes the custom metadata using a local repository instance: DONE
create a test package that provides the custom metadata in debian/control, upload to the app-review-board PPA: DONE
add support in the PPA test package(s) to upload icon metadata to the archive using the dpkg-distaddfile technique: DONE
add code to fetch icons from the archive, cache them locally and display them in app list and details views: DONE
[mvo] integrate additional archive metadata in software-center: DONE


Some snips from the previous session related to implementation:

 * Developer does the packaging
 * Per-package uploaders, can have rights to any package
 * A problem with PPAs is that users have no way of trusting
 * what promises come with Apps on the Android market place
   (note that android's sandbox makes their apps much less harmful than arbitrary .debs)

 * tells application developers to keep apps small
 * use a PPA so that there is proven maintainer
 * should be done for each version

 * App /might/ not work
 * Data should still be retained/not put at risk ** IMPORTANT ** (browser/Credit Card details/PhD Thesis)

 * Needs to be at least one Ubuntu developer on this board

 * mvo loves the idea of using something like backports, it's mirrored (but some issues)
 * maybe have another pocket
 * people can subscribe to new apps as a software source

 * how to handle applications that were installed on a stable release, then how do we
 handle +1 updates?

 * Question: Where would bug reports go?

 * We could make high-rated applications show up in merge-candidates-queues for the next developing release.

 * Can we enforce AppArmour to get them into this easy way?
 * Applications must declare their permission/resource access requirements
 * This might be tricky to enforce, I think a sandbox model for all of these apps
 * would be too complex because not all of these developers will be using Quickly.


Work Items