Ubuntu Wiki

Note: click-apparmor uses native versioning for its packaging (see X-Auto-Uploader, Vcs-Bzr and Vcs-Browser in debian/control) and therefore we don't autoincrement the version or autogenerate the changelog.

MP Submission Checklist

Note: Please ensure you include the following form filled out and submitted along side your code to the MP ticket.

• Is your branch in sync with latest trunk (e.g. bzr pull lp:click-apparmor -> no changes)

• is debian/changelog properly formatted in the MP (we use autobuilds with our own versioning, but not automerges at this time)?
  • use next native version number (eg, 0.1.14, 0.1.15.3, 0.2, etc)
  • make sure the distribution name is set to 'UNRELEASED'
  • add your changelog entries
• Does your MP have a commit message? (commit message should consist of debian/changelog without the top line or committer (ie, just the changed text, not version, name or timestamp. This commit message should be ignored if you setup debian/changelog correctly, but it is best to have it be the same in case this changes)
• Did you build your software in a clean sbuild/pbuilder chroot or ppa?
• Did you build your software in a clean sbuild/pbuilder chroot or ppa on armhf? (need for testing later)

• Does the package's autopkgtests pass with exit status '0'? Eg:

  $ adt-run -B ../binary/*.deb ../source/click-apparmor*dsc --- adt-virt-schroot trusty-amd64

  Note: first build the package then point adt-run at the resulting binaries. Building the package with adt-run will fail because certain tests run if the user is root, but the root tests fail in the schroot since the schroot doesn't have /sys/kernel/security/apparmor present

• Has your component TestPlan been executed successfully on emulator/supported device?

• Has a 5 minute exploratory testing run been executed on emulator/supported device?
• If you changed the packaging (debian), did you subscribe a core-dev to this MP?
• What components might get impacted by your changes?
• Have you requested review by the teams of these owning components?

MP Review Checklist

Note: Please ensure you include the following form filled out and submitted along side your code to the MP ticket.

Note: A Reviewer usually is responsible for a single component; since we ask for reviewers to be subscribed that might see an impact by this MP this mean that we get one-to-many reviewers contributing to the MP review process.

Below the checklist that a reviewer should follow taking the viewpoint of his component, which might or might not be the same as the component this MP is targeted against.

• verify there is a tag in trunk for the previous version (ie, the one that the MP is against). This tag is simply the version (eg, bzr tag 0.1.14)

• Is debian/changelog properly formatted in the MP (see above)?
• Is the commit message properly formatted in the MP (see above)?
• Are any changes against your component pending/needed to land the MP under review in a functional state and are those called out explicitly by the submitter?
• Did you do exploratory testing related to the component you own with the MP changeset included?
• Has the submitter requested review by all the relevant teams/reviewers?
• If you are the reviewer owning the component the MP is against, have you checked that submitter has accurately filled out the submitter checklist and has taken no shortcut?

MP Landing Checklist

• ensure that the checklists have been properly filled out by submitter and all reviewers