AppArmor is a long established upstream project that has contributors from multiple sources. The big question is whether we can treat lp:apparmor (trunk) as the trunk for our images since there are committers to AppArmor that are not Ubuntu developers. If the answer is 'yes', there is more testing up front, but with potentially less overhead overall. If the answer is 'no', then Ubuntu developers need to have a separate trunk for Ubuntu/the images and then live with any duplicated effort. How this question is answered may lead to more [TBD] entries.

For now keep upstream lp:apparmor separate from the Ubuntu trunk branch. Ie:

$ bzr branch lp:~apparmor-dev/apparmor/apparmor-ubuntu-citrain
...
$ bzr push lp:~apparmor-dev/apparmor/your-merge-proposal

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 (Eg bzr pull lp:~apparmor-dev/apparmor/apparmor-ubuntu-citrain)

• is debian/changelog properly formatted in the MP (AppArmor uses source package uploads for now)?

  • use standard Ubuntu versioning

  • make sure the distribution name is set to the devel release (eg trusty)

  • add your changelog entries
• 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? (needed for TestPlan)

• Has your component TestPlan been executed successfully on emulator/armhf Touch build (eg, one of N4, N10, N7 (either), Galaxy Nexus) and clean Ubuntu Desktop VM?

• Has a 5 minute exploratory testing run been executed on an armhf Touch build (eg, one of N4, N10, N7 (either), Galaxy Nexus)?
• 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.

• 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