Ubuntu Wiki

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

  • 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

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