LandingTeamProcess

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.

Please remember ubuntu-lt is a meta-task for Landing Team tasks - Ubuntu Touch general bugs should be targeted to canonical-devices-system-image instead.

Landing Team Meetings

The Landing Team meets up once per week on Monday UTC morning, using that time to decide on what to expect and what tasks are there for the coming week landing-wise.

Daily E-mails and Issue Tracker

During the milestone preparation, all developers plan their work as per the current OTA launchpad milestone. Those milestones include all bugs that are targeted for the given update - and this list is created by the Product Team in coordination with the Landing Team. The Landing Team Issue Tracker is used during the final candidate preparation. This list includes all bugs that currently block the release candidate from getting copied to the stable channel. The Landing Team lead sends out the current blocker list in every daily update e-mail.

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, arale, turbo, frieza, mako, generic_x86 and flo)

  2. The Product Team gives a final permission, not noting any blockers from their side (krillin, arale, frieza, turbo)
  3. Device manufacturers performing their tests (currently only krillin, vegetahd, frieza, cooler) give a green light

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

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.

Devel promotions

The devel channel follows a different scheme for image promotions. As the devel channels are not to be used for normal everyday usage, the promotion criteria are much less strict. A devel-proposed image is validated as good for promotion when:

  1. The image boots and the Unity8 shell starts
  2. Touch events work correctly and the user can interact with the system
  3. Applications can be installed and started
  4. Networking is working
  5. Developer mode can be enabled and the device is accessible through adb

Every-week on Monday the LandingTeam queries QA if the devel promotion criteria are satisfied and if the current devel-proposed image can be copied to the devel channel. If not, no promotion happens and the same process is repeated next week.

LandingTeam/LandingTeamProcess (last edited 2016-06-13 11:43:56 by sil2100)