<> The meaning intended by the word “milestone” could perhaps be better served with “iteration” or “phase”. Numbered milestones are intended to be sequential. Lettered milestones can be inserted anywhere in the timeline. “Release notes” are what we hope to be able to say when the milestone is complete. == Milestone 1: Deployed and gathering data -- DONE == '''Original estimated date:''' 2011-11-23<
> '''Estimated delivery date:''' 2012-03-05<
> === Release notes === The !MyApps server is forwarding uploaded packages to an internal pkgme service, which generates the source package. The generated source package can be obtained by asking a web op. This milestone will not have any end-user (i.e. developer) facing changes. Its main purpose is to get the system deployed and functioning end-to-end, and to give us a starting point for gathering information about the effectiveness of the system. === Risks === * Initial deployment. May get stalled on IS. [[https://rt.admin.canonical.com/Ticket/Display.html?id=48726|RT ticket]] says due on Nov 25. === Out of scope === * Launchpad / PPA interaction * End-user UI === Key actions === * Deploy the dependency database & lp:udd updating mechanism ([[https://rt.admin.canonical.com/Ticket/Display.html?id=48726|RT 48726]]) * Deploy pkgme-service with the ability to run pkgme * Have !MyApps send the submissions to pkgme-service * Make sure pkgme-service can download tarballs from !MyApps (!OpenID navigation) === Slippage === * As of 2012-02-13, approx 3 months overdue * Deployment * Lost much time due to discrepancies between developer OS and production OS * Almost all mismatch of dependency versions or unavailable dependencies * Time sunk into that * Did not know how to rectify a package not existing in lucid, had to learn * Lost much time due to round trips / waiting for IS * We wanted it deployed as sourcecode branch, asked for this in the RT, but only received instructions from IS on how to do this (and what code changes this entailed) as they got to the problem, rather than in response to our initial RT. * Integration issues between MyApps and pkgme-service * Data sent not matching data expected * Especially package_name being compulsory * We had time waiting for IS, we could have used that time to have staging MyApps talk to EC2 pkgme-service * A little time lost due to MyApps deployment schedule * One network change necessary to deployment was filed as a separate ticket, but it wasn't address as part of the ticket * The ticket was quite large, and occasionally things got lost and it took time to find it again * We have submitted patches to our puppet scripts, but there were delays on getting those reviewed & landed * Initial poor logging on pkgme-service obscured causes of communication failure between it & MyApps * Had to wait a while for IS to get around to providing credentials for pkgme-service to talk to MyApps Perhaps most fundamentally the reasons for the slippage are that we have had to rely on people who aren't actively working on automatic packaging. Note that this ''was'' highlighted as a risk. == Milestone 2: Giving reviewers access to pkgme data -- DONE == '''Estimated delivery date: ''' 2012-03-13 (depends on MyApps deployment) '''Actual delivery date: ''' 2012-03-13 === Release notes === MyApps now provides links to the package create by pkgme to MyApps reviewers. It also provides failure information if pkgme failed to actually make the package. === Risks === * Small IS dependency * Will need rollouts of each thing * Needs Apache configuration changes * [[https://rt.admin.canonical.com/Ticket/Display.html?id=51017|RT #51017]] === Key actions === * Decide how to actually serve the packages to the reviewers & implement -- DONE * Implement passing of pkgme-service failure information to MyApps -- DONE * Change MyApps to be able to receive pkgme-service failure information -- DONE == Milestone 3: Creating a package on Launchpad == '''Estimated delivery date:''' 2012-05-27 === Release notes === pkgme-service now creates a PPA on Launchpad for new packages. Again this is available to the reviewer and to us. === Risks === * No plan for how to handle upgrades of applications * Changing Launchpad is often sticky * If reason Launchpad doesn't have API for creating private and commercial PPAs is that it's unusually difficult, then that could blow the change out quite a way === Key actions === * '''IMMEDIATE''' Investigate how much work it will be to make a better API for creating private and commercial PPAs -- DONE * Extend Launchpad to have better API for creating private & commercial PPAs -- DONE * Remove `getCommercialPPAs` from Launchpad -- INPROGRESS * Investigate removing the `IArchive.commercial` attribute from Launchpad -- INPROGRESS * Email Launchpad team about the general permission problem for creating private things -- DONE * Add a celebrity and require commercial PPA creators to be members of that celebrity == Milestone 4: Publishing package to end user == '''Estimated delivery date:''' 2012-06-04 === Release notes === MyApps now automatically creates a package based on your binary tarball and makes that package available to you for test before publishing the app to your users. === Key actions === * Design UX for developer when pkgme creates the PPA for them == Milestone A: Improve dependency database -- DONE == '''Estimated time / effort:''' 1 person, 1 week === Release notes === The pkgme dependency database has been improved so that more uploaded binary tarballs can be packaged automatically. === Key actions === * '''NOT NECESSARY''' Change lp:udd to handle non-built binaries * '''DONE''' Change lp:udd to have a mode to scan binary packages rather than source. Use that. * '''DONE''' Change pkgme-binary’s fetch-symbol-files to take a binary package * '''TODO''' Update [[https://wiki.canonical.com/InformationInfrastructure/WebOps/CA/MyappsLibraryProductionStatus|production]] to scan binaries == Milestone B: Dependency database service -- DONE == '''Estimated time / effort:''' 2 weeks === Release notes === The dependency database that MyApps uses internally to automatically package binary tarballs is now available as a web service that you can use to do the exact same thing on your home system. == Milestone C: Improve binary backend -- DONE == '''Estimated time / effort:''' 2-3 days === Release notes === MyApps now respects your icons, description and license in its automatically generated packaging. == Milestone D: Provide UI for correcting guesses == '''Estimated time / effort:''' 2 weeks === Release notes === Instead of going off and building a package automatically right away, MyApps will now let you know what guesses it has made, and give you an opportunity to correct them. == Milestone E: Provide version -- DONE == '''Estimated time / effort:''' 1 week === Release notes === Can now specify the version of the package, and have that version appear in the automatically-generated packaging. == Milestone F: Upload package directly == '''Estimated time / effort:''' Only makes sense to do this after Launchpad support is enabled. Otherwise provides no real value add. === Release notes === Instead of uploading a tarball to be automatically packaged, advanced users can now upload all three elements of a source package directly. == Milestone G: More backends == '''Estimated time / effort:''' This is a placeholder for adding more backends to pkgme. Should probably be driven by what’s causing ARB the most work. == Milestone H: Improve service reliability == === Key actions === * Implement mechanism (probably using cron) in MyApps to handle failed submissions to pkgme-service * Run pkgme under restrictions on pkgme-service (limited memory usage, limited runtime)