Oxide

Revision 1 as of 2014-03-25 18:48:51

Clear message

DRAFT

Oxide is still coming online. It will have a daily build PPA for merges, but it will also have other PPAs to track Chromium Content API upstream releases. We'll need to evaluate if we do autolandings or source package uploads. For now we are doing source package uploads.

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:oxide) and packaging branch (bzr pull lp:~oxide-developers/oxide/packaging.trusty)
  • is debian/changelog properly formatted in the MP? (Oxide 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) and clean Ubuntu Desktop VM?
  • 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