ImplementationPlan

Revision 7 as of 2012-02-13 17:30:26

Clear message

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 -- IN PROGRESS

Original estimated date: 2011-11-23 Estimated delivery date: 2012-02-24

Release notes

The MyApps server is forwarding uploaded packages to an internal pkgme service, which generates the source package. The generated source package is available to reviewers and to us. Notes

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

    • 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

Milestone 2: Creating a package on Launchpad

Estimated delivery date: 2011-12-07

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

Key actions

  • Extend Launchpad to have better API for creating private & commercial PPAs

  • 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)

Milestone 3: Publishing package to end user

Estimated delivery date: 2011-12-21

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

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

  • Change lp:udd to handle non-built binaries
  • Change lp:udd to have a mode to scan binary packages rather than source. Use that.
  • Change pkgme-binary’s fetch-symbol-files to take a binary package

Milestone B: Dependency database service

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

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

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:

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.