Software::Kernel
Stabile Kernel nehmen Gestalt an
Kurz nach der Freigabe der neuen stabilen Version 2.6.11.2 des Kernels stellen Greg Kroah-Hartman und Chris Wright eine erste Version des neuen Regelwerks zur Stabilisierung des Kernels vor.
Basierend auf Vorschlägen anderer Entwickler und der Freigabe des Kernels 2.6.8.1 läutete der Vater von Linux, Linus Torvalds, eine neue Nomenklatur des Kernels ein. Zu jedem veröffentlichten Kernel (mit drei Zahlen in der Versionsnummer) soll es nach Bedarf Fehlerkorrekturen mit vier Zahlen in der Versionsnummer geben. Der als »-stable« deklarierte Baum erfährt nur Fehlerkorrekturen und wurde gestern in der Version 2.6.11.2 freigegeben. Wie die genaue Vorgehensweise der Freigabe eines stabilen Kernels funktionieren soll, erklären Greg Kroah-Hartman und Chris Wright, beide verantwortlich für die Ausarbeitung der neuen Richtlinien.
Wie nun beide Autoren in einer Email erklären, soll es auch in Zukunft möglich sein, Hotfixes für den »-final«-Kernel zu erstellen. Die strengen Kriterien, nach denen eine Freigabe einer Korrektur reglementiert wird, sehen vor, dass jede Einsendung getestet und gleich von mehreren Hackern überprüft worden sein muss. Die Patches dürfen nicht länger als 100 Zeilen sein und sie dürfen nur ein einziges Problem beheben. Das Problem muss schwerwiegend genug sein, um Probleme bei der täglichen Arbeit zu bereiten und real vorhanden sein. Probleme die theoretischer Natur sind oder Korrekturen, die lediglich Tippfehler oder »Schönheitsreparaturen« enthalten, werden nicht in einen Hotfix, sondern in eine spätere Version eingebunden.
Alle Patches, die als Hotfix in einem »-stable«-Kernel veröffentlicht werden sollen, müssen vom Maintainer des Subsystems akzeptiert worden sein. Ferner muss ein Komitee binnen 48 Stunden entscheiden, ob der Fehler kritischer Natur ist und ob die Korrektur in die Queue des »-stable«-Baumes eingepflegt wird. Sollte nur ein Mitglied des Komitees Bedenken haben oder weitere Fehler finden, so wird der Patch abgewiesen. Eine Unterschied gibt es bei sicherheitsrelevanten Updates, die nicht durch ein Komitee, sondern direkt durch das Sicherheitsteam eingepflegt werden und keinen Review-Zyklus durchlaufen.
