Landing Team Operation

Managing Workflow

The landing team will still follow the plan of 2 daily meetings a day with a reduced scope as described below. For general work management Launchpad bugs will be used.

Whenever a task needs to be escalated to the Landing Team, the landing-team-trackers team should be subscribed to the bug. If you don’t know where else to file the bug, the bug should be subscribed to the Ubuntu Landing Team project (https://bugs.launchpad.net/ubuntu-lt). The Ubuntu Landing Team project can also be added to any bugs that need the Landing Team attention as well.

Each Landing Team member is obliged to check the list of issues subscribed or assigned to landing-team-trackers. Most discussion regarding specific tasks should happen in the bug’s comments.

Landing Team Daily Meetings

The daily meetings will normally follow the following format:

• Overview of the CI Autopilot Smoketesting Dashboard for ubuntu-rtm krillin and mako
• Overview of important landings worth mentioning
• Any other business that requires direct communication

The landing meetings will no longer serve the purpose of work distribution. This is handled by LP bugs as stated above.

CI Train Operation

For ubuntu-rtm, the currently operating trainguards need to check each landing before submitting a silo:

• Check if the landing fixes only bugs that are critical and approved by the Product Team

  • The landing needs to be either:

    • Marked as [TOPBLOCKER] by a member of the Product Team

    • Approved on the Product Team's wish list
  • In case they are not, inform the upstream developers that they need to include the bug into the wish list
  • If the trainguard thinks the bugfix needs to land ASAP, escalate it to the product management
  • If the silo only fixes infrastructure issues (failing tests etc.), help escalate this landing to product management, but the fix generally is allowed to go in

• Make sure a TestPlan is attached to the landing

  • Double confirm with QA (if needed) in case the silo is set as an Isolated Bugfix not requiring QA sign-off
• Make sure that the given landing at least has a vivid counterpart assigned (or, at best, already landed in Ubuntu)
  • We need to make sure that the delta between ubuntu-rtm and the current development focus stays as small as possible

Regression Handling

QA keeps the Landing Team constantly in the loop regarding manual image testing. Whenever a new regression is detected during manual smoketesting or sanity tests, the Landing Team should be immediately informed with the bug number sent. The Landing Team, with QA’s and Landers’ help, is to check which landing in the given image caused the regression. Once this component is identified:

• The upstream developers are informed and the bug retargeted if needed

• The landing is automatically reverted in the archive if possible

  • A revert is not a punishment, but a way to give upstreams time to fix the issue properly without compromising image quality
  • The revert only happens in the archive, bzr branches of the offending projects are left intact, allowing upstreams to work on resolving it without bothering about the revert itself

• QA makes sure this specific regression is from now on handled in the given project’s TestPlan

These are the steps to perform a revert using CI Train:

1. Start a new row in the spreadsheet, listing yourself as the lander, and the source package(s) you want to revert in the "additional source packages to land" column.
2. Assign a silo to this row in the usual way.

3. Instead of "building" the silo, go to The Revert Job and fill out the name of the silo that you assigned in step 2, then click Build.

4. The revert job is basically a special case of the build job, the log output of the revert job will look just like the log output of the build jobs that you are familiar with. Watch the log as it fetches the older package version and uploads it to the silo PPA and builds the package.
5. Once the build is complete, confirm that the silo diff has the expected content (eg, the reverse of the diff from the landing that you want to revert).
6. Publish the silo in the usual way. It will automatically clean the silo as per usual as well. The end result will be that the archive now contains a new upload versioned like "2.0.~is.1.0-0ubuntu1", but the upstream trunk branch is unharmed, allowing upstreams to fix their bugs while the archive enjoys older, known-working packages.

Image Promotion

Image promotion for Ubuntu Touch ubuntu-rtm is decided whenever the following criteria are fulfilled:

1. QA has tested the image according to their QA Manual Testing process and give permission for promotion (krillin, mako)

2. The CI Autopilot Smoketesting test results show no new regressions (krillin, mako)

3. The Product Team gives a final permission, not noting any blockers from their side (krillin)

Only after all these 3 points pass a new image is promoted to the ubuntu-rtm/14.09 channel. In the normal case an image is promoted only when all devices are ready for promotion. This can be overridden by management decision.

Point number 2 will be gone from the list once QA implements their new plan for image testing, which would include considering both manual and automated testing during their test process. This would mean step 2 will be included in step 1. In any case, the Landing Team remains as the coordinator between the different teams and upstreams partaking in landing and promotion.

QA Manual Testing process

The QA Team has its own document defining the Manual Testing plan that overviews the overall process. The Landing Team only cares about the final decision of testing (passing, failing) and the bug list of newly found regressions.

https://docs.google.com/a/canonical.com/document/d/1l9ZtiXMBaGL5SteFcDKMtxDRRRtWzn8Bnp3m-UqjfZ0

The new process will take some time to come into life, so currently the process remains the same as it was before. In this case the Landing Team sends requests for image promotion testing and waits for the results.

Autopilot Smoketesting

The Landing Team keeps a constant look at the autopilot smoketesting results for consecutive images that are being produced. The image is deemed as good when the following criterion passes:

• (current) The overall number of test failures from all suites is either the same as for the previous promoted image or smaller

• (future) No new test failures are allowed other than the ones already present in the previous promoted image

The criterion currently in effect is the first one marked as (current). Once the smoketesting situation reaches a satisfactory level of quality, the Landing Team will switch to the stricter (future) criterion.