Software::Kernel
Kernel-Fehlerbändiger gesucht
Eine von Google ausgeschriebene Stelle als »Software Engineer, Linux Kernel Bug Management« ist nach mehreren Monaten immer noch unbesetzt.
Schon seit einigen Monaten fahndet Google nach einem Software-Entwickler, der Andrew Morton von einigen Aufgaben entlasten soll. Die Hauptaufgabe dieses Entwicklers wäre, Fehlerberichte zum Linux-Kernel zu verwalten, zu analysieren und sich um die Behebung zu kümmern. In den meisten Fällen wäre es damit verbunden, die richtigen Ansprechpartner auf den Fehler hinzuweisen und immer wieder nachzuhaken, bis der Fehler gefunden ist. Weitere Aufgaben des Kandidaten, der einige Mindestkenntnisse über den Linux-Kernel mitbringen sollte und den Umgang mit den Entwicklern und den Entwicklungsprozessen im Kernel beherrschen sollte, sind das Erstellen von Fehlerstatistiken, das Erstellen von Berichten über Regressionen, die Zusammenarbeit mit Benutzern und Testern und ähnliche Dinge.
Google fordert von einem Bewerber einen akademischen Abschluss, idealerweise einen Doktortitel, Programmier- und Linux-Erfahrung, Kenntnisse von Speichersubsystemen und Gerätetreibern und optional Python- und C++-Kenntnisse.
Für die Position konnte noch kein geeigneter Bewerber gefunden werden. Die Anforderungen sind zweifellos hoch und die Aufgaben schwierig. Doch Andrew Morton zeigt sich optimistisch, einen passenden Mitarbeiter zu finden.
Derweil geht die Diskussion um Fehler und Regressionen im Linux-Kernel weiter. Adrian Bunk erklärte, dass er in Zukunft keine Regressionen mehr aufzeichnen werde, da Kernel 2.6.21 trotz 14 ausstehender Regressionen veröffentlicht wurde. Andere Entwickler, einschließlich Linus Torvalds, baten ihn darum, diese Arbeit fortzuführen, da sie positive Effekte hatte. Anders als Bunk, der mit dem Ergebnis seiner Arbeit nicht zufrieden ist, halten sie es nicht für notwendig, alle bekannten Regressionen sofort zu beheben. Insbesondere hat Linus Torvalds Einwände gegen solch einen Anspruch. Die Release-Zyklen würden sich verlängern, doch die Zahl der Fehler würde nicht ab-, sondern eher zunehmen. Es sei daher besser, einige Fehler in den ersten Versionen jedes neuen Kernels (2.6.20, 2.6.21 usw.) in Kauf zu nehmen. Korrekturen würden in den stabilen Versionen (2.6.21.1 usw.) folgen. Seiner Ansicht nach funktioniert der derzeitige Prozess. Längere Release-Zyklen würden zu noch mehr Änderungen pro Version und damit mehr Fehlern führen.
