Das KernelCI-Projekt hat die Ergebnisse einer Umfrage unter Kernel-Entwicklern und -Maintainern veröffentlicht. Eine Haupterkenntnis: Per Mailingliste zugesandte Patches vor dem Einpflegen (automatisiert) zu testen, könnte sinnvoll sein.
Das KernelCI-Projekt will den Aufbau einer Testinfrastruktur rund um den Linux-Kernel professionalisieren und standardisieren. Dazu hat das Projekt nicht nur eine eigene Stiftung gegründet, sondern nun auch erstmal die Kernel-Entwickler danach befragt, wie sie ihren Code testen (und ob sie das bereits automatisch tun), wann sie Bugs im Kernel entdecken und wie lange sie warten können, bis automatisierte Testergebnisse vorliegen. Weiterhin wollte KernelCI wissen, in welche Form die Entwickler die Ergebnisse erwarten (per Mail oder als Opt-in-Benachrichtigungsdienst) und ob sie Zugriff auf die rohen Testdaten brauchen. Die Fragen und sämtliche Antworten liefert ein Spreadsheet auf Google Docs.
An der Umfrage nahmen knapp 100 Personen teil, davon waren etwa 35 Prozent Entwickler, 31 Prozent Maintainer, 9 Prozent Test-Techniker. 22 Prozent waren reine Kernel-Nutzer und 3 Prozent ordnen sich als “Andere” ein. Als Haupterkenntnis sieht der Blogpost einen Bedarf nach Tests für die per E-Mail eingeschickten individuellen Patches. Eine zweite Erkenntnis: Die automatische Bisection, die Fehler in bestimmten Kernel-Commits aufspürt, habe sich speziell für den Linux-Next-Zweig und die stabilen Release Candidates als wertvoll erwiesen. Dank ihr lassen sich Probleme direkt an die Commit-Autoren und relevanten Maintainer übermitteln, daher will das KernelCI-Projekt diese Tests ausbauen.
Regressionen und Bugs früher finden
Regressionen, so eine weitere Erkenntnis, lassen sich am besten per E-Mail an die relevanten Entwickler schicken. Um früher Berichte über Probleme mit Patches zu erhalten, müsste das Projekt auch an die Mailinglisten gesendete Patches testen, bevor jemand diese Patches in die Git-Branches integriert. 70 Prozent der Befragten seien zudem an einem Web Dashboard interessiert, auch das sei ein Bereich für Verbesserungen. Zugleich sei klar, dass einige Entwickler ein Web Dashboard komplett ablehnen, da sie nur auf der Kommandozeile arbeiten.
Was die Testzeiten angeht, genügt es den Entwicklern bei umfassenden Tests offenbar, die Ergebnisse im Laufe von 24 Stunden zu erhalten. Das sind etwa die erwähnten automatischen Bisects, die ein paar Stunden dauern können. Andererseits denkt das Projekt, dass mitunter auch für bestimmte Tests schnelle Ergebnisse wichtig sind und will beide verfolgen.
Dass Maintainer mehr automatische Tests absolvieren als Entwickler ist eine weitere Erkenntnis. Letztere erfahren meist erst von Regressionen, wenn die Maintainer ihren Code einpflegen. Testet das Projekt die per E-Mail zugeschickten Patches künftig vor dem Einpflegen, könnten einige Maintainer gegenüber den Entwicklern darauf bestehen, nur noch von der CI getestete Patches einzupflegen. Dass sowohl Entwickler als auch Maintainer bestimmte Bugs erst 24 Stunden nach einer Kernel-Release finden, deute jedenfalls darauf hin, dass zumindest in einigen Fällen frühe Tests helfen würden.
