diff options
author | Charles Kerr <charles.kerr@canonical.com> | 2014-06-30 09:54:34 -0500 |
---|---|---|
committer | Charles Kerr <charles.kerr@canonical.com> | 2014-06-30 09:54:34 -0500 |
commit | 194e79302027047ae36146f6ec4e7c0e9c1d2fc2 (patch) | |
tree | d0ce34b82460f52322d3bc9215fc7d989e642731 /MERGE-REVIEW | |
parent | eebf8f911cedf5124ada2f91576f821da6f421b0 (diff) | |
download | ayatana-indicator-datetime-194e79302027047ae36146f6ec4e7c0e9c1d2fc2.tar.gz ayatana-indicator-datetime-194e79302027047ae36146f6ec4e7c0e9c1d2fc2.tar.bz2 ayatana-indicator-datetime-194e79302027047ae36146f6ec4e7c0e9c1d2fc2.zip |
Format the manual tests properly. Update the submitter/reviewer checklist.
Diffstat (limited to 'MERGE-REVIEW')
-rw-r--r-- | MERGE-REVIEW | 53 |
1 files changed, 22 insertions, 31 deletions
diff --git a/MERGE-REVIEW b/MERGE-REVIEW index 1a5815c..88f25f6 100644 --- a/MERGE-REVIEW +++ b/MERGE-REVIEW @@ -1,44 +1,35 @@ +* '''Checklist for component''': indicator-datetime + * '''Component Test Plan''': https://wiki.ubuntu.com/Process/Merges/TestPlan/indicator-datetime + * '''Trunk URL''': lp:indicator-datetime + * '''Ubuntu Package URL (LP)''': http://launchpad.net/ubuntu/+source/indicator-datetime This documents the expections that the project has on what both submitters and reviewers should ensure that they've done for a merge into the project. -== Submitter Responsibilities == +== MP Submission Checklist Template == - * Ensure the project compiles and the test suite executes without error - * Ensure that non-obvious code has comments explaining it - * If the change affects specific features, please reference the appropriate - tags in the merge description so reviewers can test appropriately: - [phone profile], [desktop profile], [alarms] +'''Note: Please ensure you include the following form filled out and submitted along side your code to the MP ticket.''' -== Reviewer Responsibilities == + * Are there any related MPs required for this MP to build/function as expected? Please list. + * Is your branch in sync with latest trunk? (e.g. bzr pull lp:trunk -> no changes) + * Did the code build without warnings? + * Did the tests run successfully? + * Did you perform an exploratory manual test run of your code change and any related functionality? + * If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP? + * Has your component test plan been executed successfully on emulator, N4? + * Please list which manual tests are germane for the reviewer in this MR. - * Did the Jenkins build compile? Pass? Run unit tests successfully? - * Are there appropriate tests to cover any new functionality? - * Do the tag-specific tests pass? +== MP Review Checklist Template == -== Phone Profile Tests == +'''Note: Please ensure you include the following form filled out and submitted along side your code to the MP ticket.''' - * Run tests indicator-datetime/unity8* + * Have you checked that the submitter has accurately filled out the submitter checklist and has taken no shortcuts? + * Did you run the manual tests listed by the submitter? + * Did you do exploratory testing related to the component you own with the MP changeset included? + * If new features have been added, are the manual tests sufficient to cover them? -== Desktop Profile Tests == +== MP Landing Checklist Template == - * Run tests indicator-datetime/unity7* + * Ensure that the checklists have been properly filled out by submitter and all reviewers -== Alarm Tests == - - * Hardware wakeups for new alarms: - 1. Create and save an upcoming alarm in ubuntu-clock-app. - 2. Unplug the phone from any USB connection and put it to sleep. - 3. Confirm that the alarm sounds on time even if the phone is asleep. - (Note: if in doubt about sleep you can see in the syslog whether the - device actually suspended or whether the suspend was aborted) - - * Hardware wakeups for edited alarms: - 1. Edit an alarm that's already passed. (see previous test) - 2. Unplug the phone from any USB connection and put it to sleep. - 3. Confirm that the alarm sounds on time even if the phone is asleep. - (Note: if in doubt about sleep you can see in the syslog whether the - device actually suspended or whether the suspend was aborted.) - - |