Das Zugsystem besteht aus 2 getrennten Bereichen:
• dem Testsystem
• dem Aktivsystem
Jeder einfache ZugScript-Lauf, der von einem Z-Designer beauftragt wurde, erzeugt neue Züge im Testsystem. Das Testsystem hat damit auch alle Züge, die irgendwann im Aktivsystem fahren sollen. Erbauertests mit Stellwerken erfolgen immer im Testsystem und ohne Verspätungen.
Um einen Zug ins Aktivsystem zu bekommen, sind folgende Bedingungen zu erfüllen:
• die neuste Version eines Zugtemplates muß fehlerfrei per ZugScript-Lauf im Testsystem erzeugt worden sein
• für diese neuste Version muß ein Freigabeantrage gestellt werden (damit erhält diese Versionen einen Label)
• zwei Mitglieder des QS-Teams müssen der Freigabe zustimmen (Regelfall)
• alternativ zum QS-Team werden, wenn das QS-Team zu klein ist, 5 zufällig gewählte Z-Designer aufgefordert, den Zug freizugeben - zwei davon müssen der Freigabe zustimmen (Ausnahmefall)
• nach der Zustimmung der Freigabe wird ein ZugScript-Lauf ins Aktivsystem durchgeführt
Eine Freigabe kann auch mit einer Begründung abgelehnt werden, dann kann auch kein anderer die Freigabe erlauben; es muß ein neuer Antrag gestellt werden.
Vor der Erteilung einer Freigabe sollte folgendes geprüft werden:
• entspricht der Label, für die die Freigabe beantragt wurde der neusten Version - wenn nicht wurde an dem Zug vielleicht schon weiter gearbeitet, das ist zwar nicht störend aber vielleicht wurde die Freigabe voreilig beantragt
• sind die Änderungskommentare sinnvoll, z.B. wurde irgendein Bahnhof gelöscht und steht der Grund in den Kommentaren
• hat der Fahrplan des Zuges einige auf den ersten Blick erkennbare Unlogik, die zwar ein ZugScript-Lauf nicht behindert, aber unsinnig erscheint (z.B. mehrmals ein E-Flag)
Bevor man deshalb gleich eine Freigabe ablehnt, sollte man sich natürlich mit dem Antragsteller in Verbindung setzen - das Forum ist ein guter Ort dafür, möglichst das öffentliche Zug-Editor-Forum, damit 1. auch die anderen angeschriebenen Freigeber die Frage sehen und sie nicht noch einmal stellen, 2. andere vielleicht durch einen eventuellen Fehler etwas lernen und 3. es bei Konflikten oder größeren Problemen auch die R-Admins und Admins mitbekommen.
Eine Ablehnung muß immer mit einem Kommentar begründet werden.
