TRAINCON-0 Landing Mode Rules

This document tries to overview and formalize the rules and procedures for the landing team, landers and upstream developers.

When is TRAINCON-0 announced?

Normally TRAINCON-0 is automatically announced whenever more than 7 business days have passed since last image promotion to the devel channel. This mode is active until a promotable image is released and the counter resets again to 0. TRAINCON-0 can also be announced manually (forcefully) by the current Landing Team (by team decision) whenever:

• The image is badly broken and reverts for fixing are not an option
• Test results are really bad (many failures) and situation is not getting any better
• We are not able to get stable, reliable test results

Each TRAINCON-0 is documented as an incident report. Those can be found here:

https://wiki.ubuntu.com/LandingTeam/IncidentReports

What does TRAINCON-0 mean?

Landing team

Overview

• Velocity of landings slowed down
• Additionally marking landings that seem to be risky as 'Needs QA sign-off'
• Automatically publishing only isolated bugfixes or small, not broadly used features
• Queuing landings according to the risk factor
• Components that are current blockers can no longer have landings until blockers not fixed

Landers

Overview

• QA double sign-off required for non-isolated bugfixes or medium/big features before landing
• Only mark as ready to release whenever you are sure that no breakages can be caused by the given landing
• In case of blockers not yet triaged:
  • QA and Landing Team provide the image number when the blocker first appeared

  • All landers that did landings in the given image + a person from Foundations work on identifying which exact component is the source of the blocker

  • Once one blocker is identified, the lander and his team are now responsible for getting the blocker resolved - others go back to their business

Upstream development teams

Overview

• Once exact component and exact problem is identified, the developers from the team responsible fix the issue
• Team managers actively follow the progress and assign more developers and resources to help out dealing with the crisis
• Team managers actively push and prioritize on getting blockers resolved