Wenn Sie die Entwicklung von PostgreSQL in den letzten Jahren verfolgt haben, haben Sie wahrscheinlich schon den Begriff Commitfest-Manager gehört ein paar Male. Sie wissen wahrscheinlich bereits, was ein Commitfest ist, aber warum gibt es einen Manager? Da ich im vergangenen Januar viel Zeit damit verbracht habe, eines zu verwalten, werde ich es erklären.
Während des Commitfests angewendeter Patch
Im Kern ist ein PostgreSQL-Commitfest nur eine Sammlung von Patches, die darauf warten, in die PostgreSQL-Codebasis integriert zu werden. Das Arbeitsprinzip eines Commitfests besteht darin, dass jeder Patch, der an pgsql-Hacker gesendet wurde muss rechtzeitig überprüft werden; Sobald der Patch ausreichend oft überprüft und überarbeitet wurde, ist er ein Kandidat für die dauerhafte Aufnahme in PostgreSQL durch einen Committer.
Was den Commitfest-Workflow betrifft:Jeder neue Patch beginnt im Commitfest mit dem Status „Überprüfung erforderlich“; es kann als „abgelehnt“ (das zerbrechliche Herz des Autors brechend), „bestätigt“ (den Tag, die Woche oder den Monat des Autors machend) oder „mit Feedback zurückgegeben“ (wobei der Autor am Ball bleiben und wissen muss, was) geschlossen werden zu tun, um den Patch zu verbessern und ihn in einem zukünftigen Commitfest wiederzubeleben). Es gibt auch einen kurzlebigen Status „Warten auf Autor“, der für schnelles Feedback verwendet wird, das voraussichtlich in ein paar Tagen wieder zu einer neuen Version des Patches führen wird, da „Überprüfung erforderlich“. Solange wir einige Dinge als „committed“ markiert haben und Autoren gutes Feedback bekommen, geht es voran:PostgreSQL wächst, entwickelt sich und reift, um das nächste „major release“ zu werden.
So weit, so gut.
Warum brauchen wir einen Manager?
Ein Commitfest verwalten
Dem aufmerksamen Leser ist vielleicht aufgefallen, dass drei Personengruppen an dem Prozess beteiligt sind:Patch-Autoren, Reviewer, Committer. Zwischen diesen drei Gruppen gibt es viele Überschneidungen, und hier beginnen die Probleme. Um gute Reviews auf Code-Ebene durchzuführen, müssen die Leute den Code verstehen, und diejenigen, die das tun, schreiben auch eigene Patches. Auf der anderen Seite sind Committer nur Reviewer, die angeblich bessere Fähigkeiten haben sollen, Code-„Probleme“ zu finden und zu beheben. Committer schreiben auch ständig ihre eigenen Patches.
Das Problem ist, dass ein Patch-Autor, wenn er weiterhin ausschließlich an seinen eigenen Patches arbeitet, keine Zeit hat, die Patches anderer Leute zu überprüfen oder zu übertragen. Dies kann leicht passieren, wenn sie Feedback erhalten und sofort an einer anderen Version arbeiten, was zu mehr Feedback führt. Dadurch entsteht eine Schleife, die sehr lange andauern kann. Irgendwann ist es fair, dass der Autor den Patch aus dem Commitfest löscht und daran arbeitet, den Patch eines anderen zu überprüfen; aber weil jeder glaubt, dass seine Patches sehr wichtig sind, geschieht dies selten spontan.
Hier kommt der Commitfest-Manager ins Spiel. Eine Aufgabe besteht darin, das Interesse von pgsql-Hacker-Leuten zu wecken, Patches tatsächlich zu überprüfen. Meistens reicht es aus, öffentliche E-Mails an die Gruppe zu senden, um die Leute zum Lesen, Diskutieren, Testen und Nachdenken über Patches anzuregen. Häufig müssen Patch-Autoren daran erinnert werden, dass sie sich die Patches anderer Leute ansehen müssen, nicht nur ihre eigenen. Die Commitfest-Anwendung verfügt über eine praktische Schnittstelle zum Senden einer E-Mail, die dafür verwendet werden kann. Diese Dinge reichen normalerweise aus, um einen guten Quervergleich zu erstellen.
Es gibt eine alte, fast vergessene Regel:Wenn ein Patch-Autor keine Überprüfungen durchführt, können seine Patches ohne weitere Überlegungen vom Commitfest ausgeschlossen werden. Meines Wissens nach ist dies noch nie vorgekommen, was darauf hindeutet, dass Patch-Autoren zumindest bis zu einem gewissen Grad „gute Bürger“ sind.
So kann ein Commitfest-Manager, sei es durch Überredung oder Zwang, Leute dazu bringen, Patches zu überprüfen, was meistens nicht spontan geschehen würde, außer wenn Hacker bereits zusammenarbeiten.
Auf der anderen Seite lassen Patch-Autoren ihre Patches manchmal ohne Updates liegen. Eine mögliche Antwort ist, sie einfach „mit Feedback zurückgesendet“ zu schließen, aber meistens lohnt es sich, einen Autor dazu zu bringen, eine aktualisierte Version einzureichen.
Der Commitfest-Manager kann auch viel Zeit damit verbringen, eigene Reviews durchzuführen und, wenn er Commit-Privilegien hat, Patches zu committen.
Schließlich liegt es in der Verantwortung des Commitfest-Managers, sicherzustellen, dass alle Patches geschlossen sind, wenn das Commitfest vorbei ist, was normalerweise einen Monat nach Beginn sein sollte. Bei Patches, die Feedback erhalten haben und auf die der Autor mit einer anderen Version geantwortet hat, ist es fair, „den Patch auf das nächste Commitfest zu verschieben“:Das Versprechen des Commitfestes (Feedback zu geben) wurde eingehalten. Allerdings ist es unfair, dies mit Patches zu tun, die kein Feedback erhalten haben. Das Schließen von Commitfests wird in diesem Fall schwieriger.
Das Commitfest im Januar 2016
Dieses Diagramm veranschaulicht das Commitfest vom Januar 2016. Die Daten stammen aus den wöchentlichen Status-E-Mails, die ich gesendet habe:Start, Woche 1, Woche 2, Woche 3, Woche 4, Finale.
Sie können sehen, dass wir mit 85 im Status „Bedarfsüberprüfung“ oder „Bereit zum Committer“ begonnen haben, was bedeutet, dass sie darauf gewartet haben, dass jemand anderes als der Autor handelt. Eine Woche später hatten wir nur noch 71 Patches mit diesem Status:Das bedeutet, dass 14 Patches in einer Woche verarbeitet wurden, was nicht schlecht ist, denn wenn diese Rate anhält, bedeutete diese Rate, dass die gesamte Patch-Warteschlange in nur 5 weiteren Wochen vorbei wäre.
In dieser ersten Woche habe ich jedoch sechs triviale Patches übernommen. Diese gehen ziemlich schnell zur Neige, und es wird erwartet, dass die Commit-Rate sinkt. Glücklicherweise haben andere Committer hart gearbeitet, und Sie können sehen, dass die Rate der zugesicherten Patches während des gesamten Zeitraums ziemlich konstant war. Es ist wahrscheinlich möglich, dies bei allen Commitfests zu erreichen, vorausgesetzt, die Committer werden angemessen überzeugt.
Es ist ersichtlich, dass der Status „Zurück mit Feedback“ erst am Ende des Commitfests angezeigt wurde. Es setzt den Trend fort, der in der Zeile „Warten auf Autor“ zu sehen ist. Meiner Meinung nach ist das in Ordnung. Einige Leute würden es vorziehen, wenn bestimmte Patches frühzeitig „gebootet“ würden, damit sich die Bemühungen auf die Patches konzentrieren, die wirklich eine Chance haben, hineinzukommen (eine „Triage“, wenn man so will). Da bin ich mir selbst nicht sicher, also habe ich diese Idee hier nicht angewendet.
Ich denke, dieses Commitfest war mäßig erfolgreich darin, Patches zu übernehmen; der Fortschritt an dieser Front war sicherlich sichtbar, wenn auch nicht unbedingt enorm. Ich denke auch, dass es sehr erfolgreich war, sicherzustellen, dass jeder Patch-Autor eine angemessene Menge an Diskussionen über seine Patches erhielt. Ich für meinen Teil bin also mit der geleisteten Arbeit zufrieden.
Ratschläge für zukünftige Commitfest-Manager
Ich denke, dass wöchentliche Status-Updates gute Ergebnisse liefern:Es vermittelt jedem den Eindruck, dass etwas passiert (was es auch ist), und motiviert sowohl Reviewer als auch Committer, ihre Arbeit zu tun.
Außerdem habe ich den Ansatz gewählt, jedes Mal ein paar Patches aufzulisten, die Aufmerksamkeit erfordern – nicht jedes Mal die gleichen Patches, sondern ich habe mich jedes Mal auf einen anderen Satz konzentriert, um sicherzustellen, dass jeder festgefahrene Patch irgendwo einen Kick hat. Das ist subtile Arbeit:Es wäre einfacher, alle Patches aufzulisten, die Aufmerksamkeit erfordern, aber wenn Sie das tun, werden die Augen über gigantischen Listen glasig und alles wird weiterhin ignoriert.
Alle Meinungen, die Sie dazu haben, wie das Commitfest verwaltet wurde, sind willkommen. Bitte mailen Sie mir, wenn Sie es nicht öffentlich als Kommentar posten möchten. Wenn Sie denken, dass Dinge, die ich getan habe, unwirksam waren, oder wenn Sie andere Ideen haben, was zu tun ist, bin ich bereit, Ihnen zuzuhören. Ich kann in Zukunft andere Commitfeste verwalten, sofern die Ressourcen dies zulassen.
Bereiten Sie sich schließlich auf das bevorstehende Commitfest im März 2016 vor. Es wird das letzte Commitfest für 9.6 und ich bin mir sicher, dass es für alle viel zu tun geben wird. Viel Spaß beim Überprüfen des Patches!
