Product SiteDocumentation Site

1.5.3. Migration zu Testing

Etwas später wird das Paket ausgereift sein; es wird in seinen Kompilierungen für alle Architekturen keine neuerlichen Veränderungen mehr durchgemacht haben. Damit ist es ein Kandidat für die Aufnahme in die Distribution Testing - einer Gruppe von Unstable-Paketen, die unter Beachtung einer Reihe von quantifizierbaren Kriterien ausgewählt worden sind. Jeden Tag wählt ein Programm unter Berücksichtigung von Elementen, die ein bestimmtes Qualitätsniveau gewährleisten, selbstständig die Pakete für die Aufnahme in Testing aus:
  1. keine kritischen Fehler oder zumindest weniger als in der aktuell in Testing enthaltenen Version;
  2. hat wenigstens 10 Tage in Unstable verbracht, ausreichend lange, um ernsthafte Probleme zu entdecken und zu melden;
  3. erfolgreiche Kompilierung auf allen offiziell unterstützten Architekturen;
  4. Abhängigkeiten können in Testing gelöst werden oder können zumindest zusammen mit dem betreffenden Paket dorthin verschoben werden.
Dieses System ist sicherlich nicht unfehlbar; kritische Fehler werden regelmäßig in Paketen gefunden, die in Testing enthalten sind. Dennoch ist es im Allgemeinen effektiv, und Testing bereitet deutlich weniger Probleme als Unstable, womit es für viele ein guter Kompromiss zwischen Stabilität und Aktualität ist.
HINWEIS Einschränkungen von Testing
Testing wirft einige Probleme auf, die von grundsätzlichem Interesse sind: Das Gewirr gegenseitiger Abhängigkeiten zwischen Paketen ist derartig, dass ein Paket niemals allein dorthin verschoben werden kann. Da alle Pakete voneinander abhängen, muss immer eine große Anzahl gleichzeitig verschoben werden, was jedoch unmöglich ist, wenn einige regelmäßig Aktualisierungen hochladen. Auf der anderen Seite arbeitet das Skript, das Familien zusammengehöriger Pakete festlegt, unermüdlich daran, diese zu erstellen (dies wäre ein NP-vollständiges Problem, für das wir jedoch glücklicherweise einige gute Heuristiken kennen). Wir können daher manuell mit dem Skript interagieren und es lenken, indem wir Gruppen von Paketen vorschlagen oder die Aufnahme bestimmter Pakete in eine Gruppe erzwingen, selbst wenn dies vorübergehend einige Abhängigkeiten bricht. Dieses Funktionsmerkmal ist für die Release-Manager und ihre Assistenten zugänglich.
Erinnern Sie sich daran, dass ein NP-vollständiges Problem eine exponentielle algorithmische Komplexität in Abhängigkeit vom Datenumfang hat, der in diesem Fall durch die Länge des Codes (die Anzahl der Zeichen((?)) ) und der beteiligten Elemente bestimmt wird. Der einzige Lösungsweg besteht häufig darin, alle möglichen Konfigurationen zu überprüfen, was einen enormen Aufwand erfordern könnte. Eine Heuristik ist da eine ungefähre, aber hinreichende Lösung.
GEMEINSCHAFT Der Release-Manager
Release Manager ist ein wichtiger mit großer Verantwortung verbundener Titel. Der Träger dieses Titels muss faktisch die Veröffentlichung einer neuen, stabilen Debian-Version bewältigen und den Entwicklungsprozess von Testing bestimmen, bis es die Qualitätskriterien für Stable erfüllt. Er legt auch einen vorläufigen Zeitplan fest (der nicht immer eingehalten wird).
Wir haben auch Stable Release Manager, häufig SRM abgekürzt, die die aktuelle stabile Debian-Version betreuen und für sie Aktualisierungen auswählen. Sie nehmen systematisch Sicherheitspatches auf und überprüfen jeden einzelnen der von Debian-Entwicklern eingeschickten Einfügungsvorschläge, die ihr Paket in der stabilen Version aktualisieren möchten.