= 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