Deep Dive 197 –

PHP 8.5 mit Volker Dusch

09.12.2025

// Podcast
// Deep Dive 197

Shownotes

Wusstet ihr, dass neue PHP-Versionen nicht einfach wie ein automatischer Cronjob vom Himmel fallen, sondern von einem Team aus Menschen gebaut, koordiniert und durch Community-Diskussionen gestaltet werden? In diesem Deep Dive holen wir euch genau in diesen Maschinenraum: Wir sprechen über den Release von PHP 8.5 – aber weniger über einzelne Features als darüber, wie sie überhaupt in die Sprache hineinkommen und am Ende sicher bei euch auf dem Server landen.

Unser Gast ist niemand Geringeres als Volker Dusch, einer der beiden Release Manager von PHP 8.5. Volker erzählt, wie man überhaupt in diese Rolle rutscht, warum dafür keine „Bewerbung beim PHP Elefanten“ nötig ist, welche Rolle Mailinglisten heute noch spielen und wieso ein Release Manager gleichzeitig Organisator, Gatekeeper, Kommunikator und manchmal auch Feuerwehr ist. Dabei geht es um Alphas, Betas, Release Candidates, Feature Freezes – und darum, wie man zwischen Stabilität, Bugfixes und neuen Ideen balanciert, ohne das halbe Internet kaputt zu machen.

Wir schauen außerdem darauf, wie Features ihren Weg in die Sprache finden: von „unspektakulären“ Pull Requests bis hin zu großen RFCs, hitzigen Diskussions-Threads und demokratischen Abstimmungen, bei denen die Core-Contributors entscheiden, was PHP in Zukunft kann – und was bewusst draußen bleibt. Die PHP Foundation spielt dabei eine spannende, aber weniger allmächtige Rolle, als viele vermuten, und sorgt vor allem dafür, dass einige Menschen bezahlt Zeit haben, an der Sprache weiterzuschrauben, ohne dass Abkürzungen beim Qualitätsanspruch gemacht werden.

Natürlich reden wir auch über Community: darüber, warum die PHP-Welt deutlich jünger und diverser ist, als ihr Ruf vermuten lässt, was Konferenzen, User Groups und Remote-Tools miteinander zu tun haben und weshalb ausgerechnet eine „alten“ Sprache wie PHP so viele Leute anzieht, die Bock auf Sprachdesign, Performance und Internals haben.

Und weil es sonst nicht die programmier.bar wäre, streifen wir am Ende auch noch die Klassiker-Fragen rund um Generics, Async, Hacklang und die große „Kehren Firmen wie Meta irgendwann zurück zu Vanilla-PHP?“–Spekulation.

Download

/transkript/programmierbar/deep-dive-197-php-8-5-mit-volker-dusch

Jan: Hallo zu 1 neuen Deep Dive Folge hier in der programmier.bar. Ich wollt schon sagen, in welcher Kalenderwoche wir sind, aber das ist vollkommen egal bei 'nem Deep Dive, weil die sind ja zeitlos. Quasi, ja.
Dave: Ja. Es ist 48, oder? By the way? Kalenderwoche 48?
Jan: Dave, das darfst Du doch nicht sagen.
Dave: Oh, okay. Ich weiß zumindest nicht, welches Jahr. Das ist okay.
Jan: Also so schlimm ist es noch nicht, dass man das Jahr noch nicht verraten darf
???: oder so.
Dave: Ist okay.
Jan: Oder ich mein auch, also grade bei dieser Folge ist es wahrscheinlich vollkommen okay, die Kalenderwoche zu sagen, weil wir die zeitnah zu 'nem sehr akuten aktuellen Thema veröffentlichen werden. Aber manchmal nehmen wir ja doch son paar Wochen im Vorfeld auf und wenn Du jetzt gesagt hättest, wir kommen in Kalenderwoche 32 und wir wollen ja Weihnachten raus oder so, dann dann wird's schwierig. Ja, von daher, wir wollen nämlich heute sprechen über den Release von PHP 8 5 und wenn ihr euch jetzt alle fragt, HPP 8 5, das wurde doch in der letzten News Folge schon besprochen, da habt ihr vollkommen recht. Wir wollen nämlich gar nicht mal so sehr über die Änderungen in PHP 8 5 selbst sprechen, wobei da vielleicht auch noch mal kurz drüber schauen, sondern es geht eher darum, einmal darin zu schauen, so wie kommen diese ganzen Änderungen da eigentlich rein und wie kommen die ganzen Änderungen eigentlich zu euch? Und deshalb haben wir heute hier mit im Podcast den Release Manager von PHP 8 5, den Volker. Hallo Volker.
Volker: Hallo, grüß euch. Ah, folgt mich sehr, hier zu sein.
Dave: Gut, dass Du hier bist.
Jan: Volker, schön, dass Du da bist Und bevor wir hier direkt sonst in in PHP abtauchen, magst Du vielleicht einmal ganz kurz erklären, was machst Du eigentlich den ganzen Tag so, wenn Du dich nicht mit PHP oder nicht mit mit dem mit dem PHP Release zumindest beschäftigst?
Volker: Ja, genau. Ich mach seit 20 Jahren diese diese Programmiersprache mit den Dollarzeichen und die letzten 4 Jahre meinte.
Jan: Die hat deshalb die Dollarzeichen, weil man damit so viel Geld verdienen kann.
Volker: Ja, man die Deswegen, also Bash und PHP sind ja die 2 Sprachen, wo wo wo die Kohle zu holen ist, weiß man ja. Nein, die letzten 4 Jahre mach ich bei der Titways GmbH ein SARS Produkt, das Leuten hilft, ihre PHP Anwendungen zu schneller zu machen Und beschäftigt mich in dem Kontext halt sehr viel mit der Sprache selber, mit Performance, mit mit Internals, wie wie das alles funktioniert. Genau. Und bin da bin da Head of Engineering und Ingenieur für alles. 'N kleines kleines Familienunternehmen aus Bonn, für die ich jetzt seit 'n paar Jahren arbeiten darf. Und da viel Spaß.
Dave: Find ich aber auch irgendwie eigentlich ganz geil so. Wenn Du nicht mit dem Release von PHP beschäftigt bist, dann wie optimiert man es? Find ich sehr, sehr cool. So ganz lässt sich das nicht los.
Volker: Es hat es hilft natürlich, wenn man sich sowieso schon 'n bisschen mit den Internals der Sprache auskennt, dann auch besser mit den Leuten reden zu können, die dann die eigentliche Arbeit an PHP machen. Da reden wir dann ja gleich drüber. Genau. Aber der Shoutout an die Firma auch deswegen, weil die Firma mir's halt auch erlaubt, das auf zum Teil auf Firmenzeit zu machen. Und weil 1 meiner Kollegen ist auch PHP contributer, das ist dann immer schön, da jemand auch im im Firmenslag zu haben, wo man einfach sagen kann, hey, ich hab da grad eine Frage, ich versteh da was nicht. Ich soll hier irgendwie 'n Publicverse Review. Kannst Du mir mal kurz helfen? Und da ist der Tim fantastisch da zu haben als als Kontext.
Jan: Das natürlich, also das hilft bestimmt ungemein, aber vielleicht kannst Du uns trotzdem erklären, wie unabhängig von Vitamin B sozusagen, ja? Also Nein. Wird man denn überhaupt Release Manager bei PHP? Bevor wir darüber sprechen, ne, was das so alles macht und überhaupt bedeutet so, hast Du da hast Du da an irgendwen eine Bewerbung geschrieben? Hat PHP bei dir angerufen und gesagt, wir brauchen einen Release Manager? So, stand da der Elefant bei dir vor der Tür so, wie wie ist das gelaufen?
Volker: Ah, das würde mir sehr gut gefallen. Nee, die die Elefanten stehen nur im Regal, die Plüsch Elefanten, unser unser Maskottchen. Das funktioniert so, dass PHP benutzt ja ganz, ist ja jetzt der 30 Jahre Release auch, so wie andere Sprachen aus der Zeit eine Mailingliste. Aus der Mailingliste sagt dann jemand, hi, die neue Version steht an. Wir suchen Release Manager. Schreibt was
Jan: Mailinglisten, muss man das für die jüngeren Zuschauer erklären, was das ist? Ich wollte
Dave: gerade fragen, was ist das?
Volker: Ja, ja, genau. Dann sagt man so was wie, das ist so was wie 'n Forum und das hilft ja dann auch nicht. Ja.
Jan: Das ist so wie wie Discord, wenn es coole Threads könnte.
Volker: Genau, das ist so wie Discord Diskussions, ne, dass es anders wehtut. Genau. Also aber das ist eben wie wie die Sprache da funktioniert und man hat bis jetzt keine andere den Weg gefunden, das selber zu hosten. Es gab gibt natürlich Vorschläge, das irgendwie in Discord zu schieben oder in in Slack oder sonst irgendwas. Aber sone Mailingliste hat halt den Vorteil, dass sie offen ist, dass dass das alle lesen können und dass die Tools dafür existieren. Und es scheint ja auch für Sachen wie 'n Kernel zu wie 'n Niederel zu funktionieren. Also ja, genau. Aber das der letzte Job 1 Release Managers im im im Lifecycle ist für den nächsten Release jemand 'n neuen zu holen.
???: Mhm.
Volker: Deswegen hat dir jemand gesagt, hi, Announcement für die, hier könnte die Bewerbungen für den neuen Release Manager drunter posten. Dann haben sich da 3 oder 4 Leute drauf beworben und gesagt, sie hätten da Lust, das zu machen. Man stellt sich dann da son bisschen vor. Und dann können alle Leute, die auch über Features in PHP abstimmen können, da reden wir sicher nachher noch drüber, können dann auch abstimmen, wen sie denn gerne da als Release Manager hätten. Und dann ja, wie die Leute die Entscheidung treffen, ist komplett denen überlassen. Also da gibt's keine objektiven Kriterien. Das ist einfach die Leute, die auch das Recht haben, in PHP Codeänderungen zu machen, beziehungsweise an an Features mitzuvoten, dürfen halt auch entscheiden, wer die dann verpackt am Ende.
Jan: Da hätte ich da mal gleich eine Frage, weil Du gesagt hast, so die letzten oder der letzte Job 1 Release Managers ist es quasi so, den den Nachfolger zu finden oder das zumindest anzustoßen. PHP macht ja jedes Jahr einen großen Release, also dieses Jahr 8 5, letztes Jahr 8 4 und und so weiter. Genau. Aber jeder von diesen Releases wird ja länger unterstützt, ne? Also PHP Security Updates gehen ja 4 Jahre lang, glaube ich, ne? Und die Feature Updates 2 Jahre, wenn ich das noch richtig mal fasse.
Volker: Das war, glaube ich, mal richtig. Das letzte Mal mit PHP 8 mit PHP 8 1 hast Du recht. Ich glaube, heutzutage machen wir nur noch 2 Jahre und dann nee, mit 8 1 auch schon anders. Machen wir 2 Jahre aktiven Support und dann noch ein Jahr Security Support.
Jan: Okay, aber das bedeutet ja trotzdem, dass das Release sozusagen 3 Jahre gepflegt werden muss.
Volker: Genau.
Jan: Das ist Das wär ja die erste Frage. Machst Du das dann 3 Jahre und parallel zu dir gibt es dann schon irgendwann den Release Manager, der für 8 6 anfängt und den für 8 7, bis Du dann quasi aufhörst? Also es gibt immer mehrere Release Managementteams sozusagen, die so in, weiß nicht, so in in parallelen Tracks nebeneinander herarbeiten. Genau, also immer Und es gibt da keinen keine Staffelübergabe und der nächste fängt bei 0 an, sondern da sind immer schon Leute da, die quasi noch das letzte oder vorletzte Release mit betreuen, an die man sich auch mal wenden kann oder so.
Volker: Genau. Das ist das ist eine größere Gruppe an Leuten und das sind ja auch für jeden Release 2 Release Manager. Deswegen dann gleich noch die Konjunktur. Ich bin 1 der Release Manager für PHP 8 5. Der andere ist Daniel Scherzer, der ist in den USA und wir machen dann immer abwechselnd einen Release macht die eine Person, den anderen Release macht die andere Person. Aber man hat halt auch die Flexibilität, dass mir jemand mal krank im Urlaub sonst was sein kann und man sich das dann zu zweit aufteilt. Dazu gibt's immer noch einen Senior Release Manager, also eine dritte Person, die das früher schon mal gemacht hat, die dann halt der direkte Ansprechpartner ist, wenn irgendwas ist oder sollten mal beide krank sein, da einspringen zu können. Aber ja, das ist dann sone kleine Community von so 6 Leuten, die da die da aktiv sind. Genau. Und ja, ich betreu den PHP 8 5 Release für für den ganzen Lebenszyklus, also für für 3 Jahre.
Jan: Das ist, also so ehrlich muss man ja mal sagen, das ist auch 'n ganz schönes Commitment so, ne?
Volker: Ja, es ist nach dem initialen Release, wenn's dann nur die die Bugfix Patches gibt, geht natürlich deutlich weniger. Mhm. Und dadurch, dass wir auch zu zweit sind, mache ich dann einmal im Monat 'n paar Stunden was. Das ist jetzt, was Pro Bono Arbeit angeht, sehr machbar. Und wenn man dann da noch Support von der Firma bekommt, umso umso cooler. Das heißt, ja, es ist schon 'n Commitment, aber ich bin da guter Dinge, dass ich in 2 Jahren immer noch PHP mach. Insofern hat das schon Chancen. Und ja, die Sprache hat ja auch 20 Jahre mein Einkommen in irgendeiner Form gestellt. Da ist es auch mal schön, da in irgendwie 'ner strukturierten Version was zurückgeben zu können, ohne dass man sie programmieren muss.
Jan: Na ja, wunderbar. Jetzt hast Du ja schon gesagt, es gibt so diesen vorgelagerten Prozess oder Teil des Prozesses ist so überhaupt zu entscheiden, ne, was für Features kommen da rein und da wird auch abgestimmt und so was. Ist das schon Teil deiner, also wann wann fängt denn son Release Manager an zu arbeiten? Ja. Ist das quasi so vor 3 Jahren so, ja, wo vielleicht geplant wird, wann erscheint es überhaupt und wie sieht die Roadmap aus oder ist das so 2 Wochen vor dem Release, weil wir brauchen jetzt jemanden, der Social Media Werbung dafür macht und dann ist fertig? Also wann wann fängt das an?
Volker: Genau. Also meine erste meine erste offizielle Amtshandlung neben der Bewerbung war am dritten Juli, wo wir die die erste Alpha rausgebracht haben zum Testen. Und das funktioniert so, dass p, der aktuelle p p Release wird auf der Main Branch vom Repository entwickelt bis zur ersten Betaversion. Und da wird dann oder bis zum, nee, sorry, bis zur ersten Betaversion, dann ist Feature Freeze, dann ist sone kleine Stabilisierungsperiode, wo das auch immer noch auf der Main Branch von Repository weiterentwickelt wird. Und mit dem ersten Release Candidate am fünfundzwanzigsten September jetzt, da geht es dann in einen neuen Branch drüber. Und wenn sobald es in 'nem eigenen Branch ist, ist alles, was da reinkommt, irgend soll irgendwie an an mir oder an Daniel vorbeigehen. Außer es sind halt klar Debugfixes und die Leute, die sich jetzt beim PHP im Security Team die Security Fixes kümmern, die wissen schon, was sie tun. Das muss man dann nicht koordinieren. Also es ist auch keine Frage, wollen wir einen Security Fixes in einem Release haben? Das ist die Antwort ist halt ja und fertig. Sondern das geht dann halt nur drum, wenn wenn's da wenn's da Fragen gibt. Das heißt, der Weg, wie wie das im PHP funktioniert, mit was kommt eigentlich in einen Release, ist einfach alles, was das ganze Jahr passiert ist. Und sobald's dann in die Betas geht und an die Stabilisierung, dann ist jetzt Praxis, dass ich oder dass 1 von den Release Managern so die pull requests alle noch mal approved und sagen, ja okay, das macht noch Sinn, das ändert jetzt nix grundlegend. Das invalidiert nicht irgendwie Testing, dass Leute schon in Alpha Versionen dann gemacht haben. Das macht irgendwie noch Sinn. Da haben wir, das ist 'n sinnvoller Bugfix oder noch eine sinnvolle Addition, die die jetzt nichts kaputt macht. Genau. Und dann ist es son bisschen unser Ding, da im Loop zu sein und und und da zu fragen. Das ist auch der Hauptteil der Arbeit gewesen. Also das das eigentliche Verpacken ist relativ harmlos, sondern eher dann halt zu gucken, was kommt da rein?
Jan: Und wenn Du jetzt aber sagst, so deine erste Amtshandlung war quasi den den ersten Alpha Release im Sommer zu machen, Mhm. Dann impliziert das ja schon, das, was da war, was es überhaupt zu releasen gab. Und Du hast ja eben gesagt, ne, also alles, was quasi seit dem letzten Release quasi in den Branch gelandet ist, geht dann da so mit mit raus. Vielleicht können wir da son bisschen auch kurz drüber sprechen. Ja. Wie kommt denn so überhaupt was in sone Sprache rein?
???: Weil das ja
Jan: jetzt nicht so, dass ich hier als Jan zu Hause mir irgendwie das PRP Repository nehmen kann und sage so, ah, ich wollt schon immer mal die Reihenfolge von diesen Parametern ändern. Diese ganzen Array Funktionen regen mich tierisch auf und jetzt jetzt räume ich hier mal einmal auf und dann schiebe ich das zurück. Wie ist denn da der Prozess?
Volker: Ja, es ist gar nicht so viel komplizierter. Vielleicht werden wir Meine Chance sein. Das war
???: schon jetzt
Volker: die Reihenfolge, wenn der Array Parameter ändern willst und damit allen Code kaputtmachen, der der der der so im Internet läuft, da hat vielleicht die ein oder andere Person eine Idee dazu, dass das dass das anders sein besser wär. Aber die wirklich kurze Antwort ist, wie kommen Features in PHP? Leute bauen die halt. Und dann gibt's 2 dann gibt's 2 Arten von von von wegen, wie das funktioniert. Also man kann an das PHP Source Repository in den Pull Request stellen und sagen, hi, ich hab hier was eingebaut. Ich glaub, das würde Sinn machen. Ich glaub, das ist nicht kontroversiell. Ich glaub, da muss man nichts drüber reden. Das macht einfach Sinn oder das ist 'n Bugfix oder sonst irgendwas. Und dann sagt sagen Leute die die C-Code-Bas-Mainan ja oder nein dazu. Und wenn da 3 wenn da 2, 3, 4 Leute ja sagen, dann wird das gemergt und dann ist das einfach drin und fertig. Also da da gibt's einen relativ kurzen Weg, das zu machen. Wenn Du jetzt irgendwas Größeres machen willst oder wenn wenn's da irgendwie Diskussionsbedarf gibt, dann sagen die Leute, na ja, das wollen wir jetzt nicht einfach so entscheiden, da haben wir 'n Prozess dafür. Und dann schreibst Du einen request for commons. Also ein ein RFC im PHP Wiki. Das funktioniert im Großen und Ganzen so, Du kriegst da 'n Template und füllst dann da 'n Form aus, wo halt drinsteht, ich find das sinnvoll, weil und was geht dann kaputt? Und da schreibst Du im Zweifel nicht das ganze Internet rein, sondern ja nichts halt. Oder also Du beschreibst dann halt sinnvoll, was was die Implikationen von 1 Änderung sind. Dann wird das auf der Mailingliste diskutiert für 2 Wochen. Dann gibt's eine 2 Wochen Abstimmungsphase. Sorry ab, ja genau, doch Abstimmungsphase. Also da wird dann drüber abgestimmt und wenn Du dann eine Zweidrittelmehrheit für deinen Change trägst, dann geht der rein. Dann passiert nachher noch das Technical Review auf GitHub, aber das ist so, wie das PHP Projekt entscheidet, welche Features in welche Features man haben will oder welche oder sonst irgendwas.
Jan: Das dient jetzt ja alles eher nach 'ner sehr technischen oder oder fachlichen Diskussion, so, ja. Ja. Jetzt muss ja aber vielleicht auch so was geplant werden wie, na ja, das könnte in den nächsten Release oder lass mal noch irgendwie den übernächsten abwarten, weil wir haben da was, was irgendwie darauf aufbaut oder das ist als Change irgendwie so groß, dass wir das in einen Major Release packen wollen aus Gründen so, ja. Ja. Wer entscheidet denn so was, wenn das im Prinzip schon vor dem Release Management entschieden werden muss?
Volker: Ganz grob gesagt niemand. Also soll das in einen Major Release? Die Antwort ist eigentlich immer, nein. Weil das Einzige, was 'n Major Release macht, ist Deplications zu Deplications Kaputt
Jan: zu machen.
Volker: Auszubauen und die die Sachen wirklich rauszunehmen. Also das Einzige, was macht, wenn die wenn die große Zahl höher wird, ist, dass halt was kaputt ist. Und die die meisten Features kommen in den in den Miner Releases im PHP Wein. Also zwischen PHP 8 8 1 und 8 5 ist deutlich mehr featurtechnisch passiert, als jetzt wahrscheinlich in PHP 9 passieren würde. Es gibt natürlich große Features, die die Sprache so grundlegend ändern und jetzt sind's auch schon wieder 5 Releases, dass dann mal jemand irgendwie vorschlägt, entweder auf der Mailingliste oder sonst was zu sagen, lass uns die nächste Version doch 9 nennen und dann mal aufräumen. Da macht dann jemand einen einen Vorschlag, ja, auf der Mailingliste, da wird dann drüber abgestimmt, ob die nächste Version dann der Major sein soll und dann macht man das. Das würde jetzt, wenn wir jetzt sagen, wir wollen PHP 9 als nächste Version machen, wahrscheinlich so im Januar spätestens mal jemand vorschlagen, weil man will dann ja auch 'n bisschen Zeit haben, dann auch wirklich aufzuräumen. Und dann auch, wenn man schon die die Deplications umsetzt, dann möchte man da ja auch die Benefits haben. Also da soll dann ja auch Performance besser werden, da soll dann die Code Base einfacher werden. Dann sollen die Leute schöner leben können, 'n paar Sachen updaten, bisschen modernisieren, wenn man schon mal die Chance hat. Aber da gibt's jetzt keinen, also es gibt keinen keinen Council, das irgendwie dasitzt und sagt, wir in den nächsten 3 Jahren machen wir die folgenden Dinge. Sondern das sind wirklich einfach 'n Haufen Individuen, die da halt an Sachen arbeiten, die die gut finden. Das ist, die letzten Jahre hat sich das jetzt mit der PHP Foundation, da reden wir später noch 'n bisschen drüber 'n bisschen geändert, die hat natürlich schon einen Plan und Ziele und Sachen, die die die Leute, die da hinspenden, irgendwie gern hätten. Aber die Leute, die bei der PHP Foundation arbeiten, sind auch nur einzelne Leute, die halt auf der Mailingliste dann Sachen sagen und vorschlagen. Und der Prozess funktioniert auch so, obwohl es da noch eine Foundation gibt. Also das PHP Projekt ist ja da weiter unabhängig davon. Auch wenn die Zusammenarbeit da sehr gut funktioniert.
Jan: Ich mein, dann lass uns doch da direkt drüber sprechen. Ja. Die PHP Foundation ist ja, also im Vergleich zu PHP eine relativ junge Einrichtung, so.
Volker: So ist dem.
Jan: 'N paar Jahre jetzt, glaube
Volker: ich, dass ich 21 22, wenn ich mich richtig erinner.
Jan: Genau. Und wie Du schon auch gesagt mein Verständnis ja auch im Prinzip davon losgelöst, außer dass es halt viel Goodwill gibt, halt PHP da zu unterstützen, aber quasi rechtlich systemisch sozusagen vollkommen entkoppelt. Aber wie gestaltet sich da die die Zusammenarbeit?
Volker: Genau. Also ob's wie wie komplett rechtlich das alles entkoppelt ist und wer da welche Lead Trademark oder sonst was hält, muss ich sagen, weiß ich gar nicht. Da bin ich nicht in den in den Details drin. Aber von genau, von dem Entwicklungsprozess selber ist es nicht so, dass nur weil jemand irgendwie von der Foundation eingestellt wird, die jetzt einfach Sachen in PHP committen können, ohne dass das irgendjemand stören würde. Sondern das geht alles durch die durch die normalen Prozesse an der Stelle. Genau. Sorry, ich hab, kannst Du die Frage noch mal wiederholen? Die war gut.
Jan: Also was was mich eigentlich mehr so interessieren würde ist, ne, weil Du ja, Du sprichst auch immer so von der Mailingliste und die PHP Foundation zahlt ja auch irgendwie Leute, die an PHP quasi mitarbeiten. Und ich frag mich son bisschen, so Henneeimäßig, wie kommt das halt zustande, ne? Bezahlt mich die die PHP Foundation und dann mach ich was am PHP oder werde ich schon irgendwie PHP Maintainer, komm mal auf diese Mailingliste und dann hab ich irgendwie eine Chance von der Foundation unterstützt zu werden? Also wie wie komme ich so in den Inner Circle von PHP sozusagen?
Volker: Ja, das ist keine Nachfrage. Deswegen hab ich's auch anders formuliert, weil ich's nicht als inner Circle betrachten würde. Weil die Leute, die für die Foundation arbeiten, sind sind jetzt nicht unbedingt mehr Core Team als andere Leute. Also mein mein Kollege Tim, der von Titways bezahlt wird, Sachen am PHP Core zu machen, ist genauso Chor wie wie Andy Stoshe, der in in 'nem kleinen europäischen Land an der Uni sitzt und da supercoole Sachen in PHP einbaut, im Vergleich jetzt zu Ilja oder Jakob, die für die Foundation arbeiten. Und die kennen sich auch von vorher und die haben halt Sachen gemacht. So was wie das funktioniert ist, die Foundation sagt einmal im Halbjahr oder Jahr, wir wir sind offen für Bewerbungen. So, wenn wenn Du Sachen an PHP machst und man dich im Zweifel man dich kennt, bewirb dich doch. Wenn Du das wenn Du das irgendwie gern für auch wenn Du da Geld für hättest Und wenn Du das zu 'nem strukturierten Teil deiner deiner deines Lebens machen möchtest und das halt, ja, als deinen Job machen möchtest, anstatt das als als als Volontier contributions zu machen. Die Foundation ist jetzt natürlich noch jung, wie man die ersten Core Developer gefunden hat, war, glaube ich, eher ein, oh, diese Leute machen viel. Dann redet man mal mit denen, hey, hättest Du da Bock drauf? Was machst Du eigentlich sonst so beruflich? Ist das was, was Du dir vorstellen könntest? Und ich denk auch, dass es so wie bei jedem Open Source Projekt ist, dass man ja sieht, wer die aktiven Leute sind, dass die Leute, die am Chor arbeiten, auch sehen, hey, da ist eine neue Person, die ist seit 'nem halben Jahr da, die macht viele tolle Sachen. Lass uns doch mal mit der Person reden, ob das sinnvoll sein könnte. Genau, aber der Bewerbungsprozess ist insofern offen, dass das die Foundation da auch offenlegt, wer sich da, weiß ich gar nicht, ob sie offen liegen, wer sich da beworben hat, aber dass es einen Bewerbungsprozess gibt und dass sie dann sagen, und das sind jetzt die Leute, die wir da bezahlen. Genauso wie auch alles, was die Leute bekommen, auf dieser Open Kollektiv Seite eben einsehbar ist. Sodass man da auch ja einfach Transparenz schafft.
Jan: Okay. Jetzt haben wir ganz lange darüber gesprochen, wie so Sachen eigentlich in PHP reinkommen. Versuchen wir mal, die Kurve zurückzukriegen zum Release Management. Ja. Du hast vorhin gesagt, wieder deine erste Ansammlung war war eben dieser Release. Jetzt frag ich mal ganz ketzerisch. Ja. So PHP, egal wie alt das ist, hat ja bestimmt schon irgendwie 'n einigermaßen modernen Release Prozess und da passiert automatisch sehr viel auf CI- und CD Ebene so. Was macht denn dann son Release Manager, außer auf son Knopf zu drücken, dass da jetzt mal son Release gebaut werden soll?
Volker: Ja, leider mach ich sogar noch 'n bisschen mehr, als auf son Knopf zu drücken. Ich hätt da, ich würde auch gern lieber nur aufn Knopf drücken. Da da fehlen da fehlen noch 'n paar da fehlen noch 'n paar Kleinigkeiten, beziehungsweise den in einem 30 Jahre alten Projekt halt auch 'n paar Sachen, die man die man so aus historischen Gründen noch so macht.
Jan: Das haben wir schon immer so gemacht.
Volker: Ja, nicht mal das, sondern so. Das das ist halt so, hat hat grad mehr Lust, das zu ändern. Haben keiner da. Es gibt zu viele andere spannende Sachen, die man grad machen könnte. Und der Prozess funktioniert halt im Moment für alle. Genau. Aber ich erzähl dir mal son bisschen, wie das funktioniert. Oder euch. Genau. Und zwar ist es so, dass ich an jedem zweiten und vierten Dienstag im im oder immer im im 2 Wochen Zyklus gab's diese Alphabeter- und Release Kandidat Releases, das das die Leute testen können. Und ich gehe dann am am Dienstag irgendwann untertags hin, guck mir das Repository an, guck, ob diese ei grün ist. Wenn diese ei nicht grün ist, rede ich mit Leuten, warum diese ei nicht grün ist. Und mach dann einen Tag auf das Repo. Dann müssen dann noch 'n paar Dateien generiert und angepasst werden, wo halt eben die Versionsnummer drinsteht und sonst was. Also die ganze Implementierung, das sind dann irgendwie 3 Dateien, die man noch anfasst. Macht dann da Tabballs aus dem Release, also das PHP Projekt selber released keine binaries, das released nur Tabballs. Und ja, taggt die dann, lad die auf meinen privaten Webspace, der noch sone lustige Tilde im Namen hat, wie es, wenn man an der Uni arbeiten würde seinerzeit, auf auf Downloads Punkt PHP net Slash Tilde Dorian hoch. Lad da noch 'n Manifest File hoch, lade 'n Manifest File auf meinen auf meinen GitHub Account und schick dann an die schick dann an eine bestimmte Mailingliste, wo eben die ganzen Leute, die sich mit dem Releaseprozess beschäftigen, eine Notiz, dass jetzt der Tabball gebaut, gesigned, reviewt und und ready ist. Und dann kommen Leute, machen die Windows binaries dafür. Dann kommt Rammy von von Redhead und baut da die die RPM Pakete draus und sonst was. Die Leute, also grad grad Lemmy und und dass 'n Arbeiter von Redhead bezahlt wird, macht er extrem viel, zu gucken, dass er auf die ganzen PHP Extensions alle bauen. Und bicks da dann auch Sachen, wenn da wenn's da irgendwelche Probleme gibt, was dem Projekt da auch sehr weiterhilft. Genau. Und das passiert am Dienstag. Dann haben die Leute 2 Tage Zeit, so ihre Binarys zu bauen und vorzubereiten und am Donnerstag announcen wir dann das Release. Bin noch.
Jan: Jetzt hast Du bist Du so relativ schnell da durchgesprungen, so, wir machen diese Alpha-, Beta- und Release Kandidat eben so. Habt ihr da oder oder wie differenziert ihr denn für euch so, das ist noch eine Alpha, das ist jetzt schon eine Beta und das fühlt sich hier nach sonem RC an und jetzt sind wir hier ganz fertig und das ist der finale Release. Ja, das
???: ist Habt
Jan: ihr da so feste Kriterien oder oder ist das so in eurer Verantwortung?
Volker: Die persönliche, also man kann als Release Manager, wenn man Gründe hat, an diesem Prozess was ändern und wenn man sagt, hier ist, glaube ich, 'n Problem, das wär besser, wenn wir das anders machen würden. Aber das ist eigentlich alles durch den Prozess vorgegeben. Also als ich angefangen hab mit mit dem ersten Alpha Release und da vorher mit Pjervik, der der Senior Release Manager für diesen Release ist, 'n Gespräch hatte, hat der schon den kompletten, den kompletten Google Docs Kalender für alle Releases bis zum Ende von 8 5 fertig gehabt. Weil wir eben gesagt haben, wir machen 4 Alpha Releases, 3 Beta Releases und 4 Release Candidots Und das immer im 2 Wochen Rhythmus und daraus ergibt sich dann einfach der Kalender. Also der der PHP, der erste stabile Release jeder PHP Version kommt einfach aus historischen Gründen immer so im am dritten Donnerstag des Novembers raus. Also jetzt dieses Mal war's der zwanzigste November, aber immer so was die in die Richtung und dann rechnet man von da zurück und dann ergeben sich die Daten von selber. Ja. Das
Jan: ist ja aber auch einfacher gesagt als getan, ne. Also ich mein, jetzt zu sagen, okay, es gibt immer diesen diesen magischen Tag im November, wo sone PHP Version veröffentlicht wird, ist ja das eine. Aber dann bei 'nem Open Source Projekt halt auch dafür zu sorgen, dass dann halt auch alles fertig ist bis dahin ist ja das andere, ne. Ich mein, wenn Du jetzt einfach sagst, na gut, wir nehmen alles mit, was bis dahin irgendwie so im Mainbrunch gelandet ist, das ist ja noch längst nicht alles backfrei, weil sonst bräuchte man ja diese ganzen Reces nicht. Ja. So und dann ist es ja bestimmt auch irgendwie Teil deines Jobs, so den Leuten auf die Füße zu treten und mal höflich anzuklopfen und sagen so, hier cooles Feature, was Du da gebaut hast, ist aber noch XYZ kaputt. Das müsste jetzt mal dringend gemacht werden, weil im November geht's halt irgendwie raus an die halbe Welt. So. Wie wie muss ich mir das vorstellen, wenn man so fürn Release verantwortlich ist, aber ja im Prinzip überhaupt gar keinen Hebel so den Leuten gegenüber hat, die da eigentlich den Code verschreiben müssen?
Volker: Das ist Ich weiß nicht, wie das vor 5 bis 10 Jahren in PHP war. Das ist heutzutage ist das auch sehr entspannt, weil sowohl dadurch, dass die Foundation halt 'n paar Leute hat, die das hauptberuflich machen, als auch dadurch, wie halt Es werden halt nur Sachen gemerged, die stabil sind in in diesen Mainbrunch. Also wenn das Feature nicht fertig ist, dann wird's halt nicht dann wird's halt nicht gemerged. Kann man sich da sowohl darauf verlassen, dass die Sachen, die drin sind, eigentlich in der Regel ganz schon ganz gut und stabil sind. Also PHP hat ja irgendwie 40, 50000 Tests, zu gucken, dass die Sprache so weit funktioniert. Und wenn die alle durchlaufen, dann kannst Du schon so viel gar nicht kaputt gemacht haben. Und wenn man dann noch 'n SEQUD findet, dann findet sich auch jemand, dann den SEQUD zu fixen. Und grad jetzt die die Zeit vom vom zwölften August jetzt ab, ist dann haben Feature Freeze, das heißt, da sind dann auch einfach 6 Wochen, wo keine neuen Features in in den Mainbrunch gemerged werden, sodass die Leute da auch 'n bisschen Zeit haben, sich Bugfixes zu kümmern. Also wenn dann in der Zeit jemand was contributen möchte, dann ist das halt der natürliche Ding, dann sich noch mal anzugucken, gibt's denn schon Bugs für den Release oder so? Aber da ist sind auch die die Core Developers ja hinterher. Also auch die Leute, die die Features submitten, machen das schon mit dem Anspruch, dass ihr Feature dann auch gut ist. Das heißt, man muss den Leuten sehr wenig hinterherlaufen, weil die es doch sehr, ja, Iger sind und das einfach selber fixen möchten. Genau. Und dazu kommt einfach, dass mit mit der Foundation jetzt einfach 6, 6, 7 Leute, die eigentlich jeden Bug fixen können, auch da sind. Und da findet
???: sich dann auch jemand,
Volker: weil die Leute halt auch 2
???: Sch
Jan: 2 Schrägstrich zweieinhalb Mhm. Mit einem etwas seniorigeren Partner noch dazu, Release Manager. Wie teilt ihr die Arbeit unter euch auf?
Volker: Genau. Wir haben uns ganz am Anfang, also Pierre, unser unser Senior LM hat ja diesen diesen Google Kalender gemacht mit, hier sind die ganzen Releases und Du und Daniel, ihr geht mal rausfinden, was ihr da machen wollt. Der Prozess ist dann diesem Team an Leuten überlassen. Ich hab mit Daniel dann gesagt, wir machen einfach abwechselnd. Das ist einfach das ist einfach zu zu wissen, so, hab ich vor 2 Wochen was gemacht? Ja, dann bin ich jetzt nicht dran. Hab ich vor 2 Wochen was gemacht? Nein, ah, dann bin ich jetzt dran. Das so, das das das ist einfach, sich zu merken. Das kann man auch vorplanen. Und für die Reviewarbeit ist es so, dass Daniel hat 'n bisschen mehr C- und Chor Erfahrung als ich. Der hat auch, also ich hab im aktuellen PHP Release 5 RFCs, also 5 Features mit drin. Da hat aber Tim viel von dem Code dafür geschrieben und ich mehr von dem von dem Management Kram drum rum gemacht. Ich kann relativ flüssig Zeh lesen. Ich würd mir jetzt nicht zutrauen, irgendwie jeden Sackpoint zu finden und und jedes Problem zu finden. Das heißt, was das was die Review von Sachen angeht, ist es eher so, dass wir uns auf die Leute, die die 10 machen, verlassen, den die die technische Review zu machen und wir überlegen uns dann eher, passt das in den Release rein? Da haben wir in der Alfa und in der Betaphase zwischen mir und Daniel gesagt, wenn 1 von uns sagt, das ist okay, dann können die Sachen allein. Und für die Release Kandidatphase haben wir gesagt, da wollen wir beide zustimmen. Einfach, dass wir da sicher sind, dass da 2 Leute kritisch drauf geguckt haben, ob's so spät im Prozess noch Sinn macht, da noch irgendwas zu ändern. Also ob's noch noch zu verändern, wie 'n Feature funktioniert oder sonst irgendwas. Genau. Und die Kommunikation da findet über über einen semipprivaten Slack, in dem wir beide drin sind statt, wo wir einfach miteinander chatten, wo auch 'n paar von den anderen Release Managern sind. Es gibt ja den PRPC Community Discord. Da sind 'n ganzen Haufen Leute, die auch Internals machen drin. Aus historischen Gründen gibt's noch Room Eleven, also vom Stack Overflow Chat, Falls man das nicht wusste, es gibt Stack Overflow noch. Es gibt auch noch einen Stack Overflow Chat. Es gab gab auch schon immer einen Stack Overflow Chat. Und aus historischen Gründen hängen da 'n ganzen Haufen Leute, die PFP Core machen, bumm. Wo auch einfach da viel diskutiert wird. Und dann, ja, gibt's halt so die Park Community, Watering hols, sag ich mal, wo man sich dann trifft und wo die Leute sich sich organisieren.
Jan: Interessant. Jetzt ist ja PHP 8 5 veröffentlicht und damit hoffentlich der der große Anteil deiner Arbeit getan. Oder oder der der schwierige Teil des Prozesses hinter dir, sagen wir mal so.
Volker: Genau. Der der Punkt 1 Release ist ist meistens noch 'n spannender, weil dann weil's dann gibt's ja im Zweifel die ersten größeren Bugfixes oder vielleicht mal noch eine Diskussion hier oder da. Das hat jetzt diesen Release wieder ganz gut funktioniert. Ich hab jetzt wenig wenig gesehen, was irgendwie grob kaputt war. Und ja, danach solltest 'n bisschen entspannter hoffentlich weitergehen.
Jan: Und wenn Du jetzt auf diesen Zyklus zurückguckst, was waren so die besonders anstrengenden Momente?
Volker: Ja, es durch diesen RFR Prozess ist es natürlich so, man hat 'n ganzes Jahr Zeit, was zu tun. Das heißt, man macht's in den letzten 4 Wochen. Klassiker.
Jan: Aber Studenten kennen das.
Dave: Ja,
Volker: Genau. Also und dann ist eben die die letzte Zeit, also da wo am meisten in den in in PHP reinkommt, natürlich auch die Zeit kurz vorm Release, wo dann auch noch mal die meisten Bugs gefunden werden, wo die meisten Diskussionen passieren und wo dann auch manche von den Features das erste Mal wirklich ausprobiert werden. Also die die RFCs haben schon einen relativ hohen Qualitätsanspruch, aber es gibt auch, ich sag mal, es gibt Leute, die die RFCs schreiben, die sich sehr viel über technische Edge Cases Gedanken machen, die halt bei Sprachdesign sehr wichtig sind. Und es gibt 'n paar Leute, die eher so große Ideen haben. Und wenn man eine große Idee hat und da nicht viel über die Edge Cases nachdenkt, dann ist es halt zum Teil auch das Problem der Mailingliste, diese Probleme zu finden und von anderen Leuten da mitzudenken. Aber die machen das im Zweifel alle nicht so gewissenhaft, wie die Autoren das im Zweifel hätten tun sollen. Und dann findet man halt unterwegs noch 'n paar Sachen raus, die 'n bisschen hätten besser sein können. Und da war dann viel Diskussion, so wollen wir den fix noch mit reinnehmen? Wollen wir den fix noch mit reinnehmen? Ah, das Feature ist ja gar nicht so rund. Und da gab's dann auch 'n paar Stellen, wo man mal rumlaufen musste und sagen, wie fixen wir das jetzt noch? Also ihr habt ja vielleicht dann letzten Monat über den Pipepropallator gesprochen. Da gab's ja noch in der AC Phase noch eine Änderung, dass man jetzt wenn man da eine Funktion übergibt, immer eine komplette Klammer die Funktion rum machen muss nach nach nach jedem von den Pipes. Das ist sehr spät erst rausgefunden worden, wo dann Leute angefangen haben, das in Extensions einzubauen. Also als X-D-Bulk versucht hat, dann mit diesen Pipes zu arbeiten, hat man dann gemerkt, ah, das funktioniert nicht ganz so, wie's funktionieren sollte. Und das waren dann halt noch noch größere und ich sag mal, 'n bisschen hektischere Momente. Oder es gab auch wieder viele viele tolle Deplications, die mir sehr gut gefallen haben in in diesem Release, wo man wieder viel aufräumen kann. Und wenn man da 35, 40 Sachen ändert, dann sind halt ein, 2 Sachen dabei, wo man dann raus findet, oder ist jetzt Composer kaputtgegangen oder oder ist jetzt was eine Symphony, was die nicht einfach fixen können? Und dann macht man da noch mal 'n Follow-up, vielleicht machen wir's doch nicht jetzt oder sollen wir's anders machen. Genau. Da ist aber auch 'n großer Vorteil davon, dass halt die die wirklich Kerntools von von PHP, also ich sag mal Composer PHP Unit und das Symphony Projekt sind so die 3 Tools, die wirklich am meisten Feedback geben und die auch mit jeder Alpha und mit jeder Beta alles testen und auch wirklich gucken, dass die Software läuft. Und wenn man die 3 Tools gecovert hat, also wenn wenn wenn Du's installieren kannst, wenn deine Tests laufen und wenn dein Framework läuft, dann ist schon sehr viel, sehr viel gewonnen. Und da Larawelle zum guten Teil auch auf Symphony Componce benutzt, funktioniert da dann im Zweifel auch relativ viel schon.
Jan: Also ich wollt grad sagen, wenn man wenn man so die PHP Projekte anguckt und alle abzieht, die nicht Composer und oder Symphony benutzen, dann bleibt wahrscheinlich auch nicht mehr viel vom Internet übrig.
Volker: Ja, benutzt Whitepony.
Jan: Also Wikipedia und und WordPress bleiben übrig wahrscheinlich, ja. TropAL, Magento, bla, die sind da alle schon weg.
Volker: Ja, genau. Aber Drupa benutzt noch Symphony, genau. Shopware, Magento auch, Comporrents, ja. Genau. Die meinen, die Projekte haben dann selber auch noch mal Code. Aber allein, also ich hab ich hab schon 'n paar Mal 'n Release veröffentlicht und dann am nächsten Tag eine DM von 1 der oben genannten Projekte gehabt mit, warum, weil unsere Bild sind jetzt kaputt, please at weiß. Und dann ist es halt so, ist das was, was das PHP Projekt fix oder ist das was, was die Projekte fixen? Das ist schon ganz cool. Also dass die Leute einfach da wirklich sehr gewissenhaft auf auf den den Main Branch testen, ist einfach super. Ja.
Dave: Ja. Jan hat gerade über eher was Negatives gesprochen, also etwas, was da richtig stressig war in in der Phase. Gab's etwas, was so richtig cool fand, irgendwie 'n bestimmtes Feature, irgendwas, was richtig butterweich lief als Release Manager, eher die positive Seite davon?
Jan: Mhm.
Volker: Ich muss sagen, ich war sehr happy, wie wie hilfsbereit und wie wie viel Zeit sich die, also wie hilfsbereit die Leute sind und wie viel Zeit sich die nehmen für einen dann, wenn man wenn man da fragen hat, ja was baut das Onboarding? War super? Also wir saßen dann da nach dem Vote hat man sich dann irgendwie erst mal über LinkedIn verknüpft und einen gemeinsamen Chat Channel gefunden. Und dann saßen wir da in 'nem Call und Pjerdeck hat sich da 'n paar Stunden Zeit genommen. Die ganze der ganze Releaseprozess ist ausführlich im PHP Source Repository dokumentiert. Und der geht dann so die Liste durchgegangen, dann hat man das einmal alles auch lokal gemacht, geguckt, dass das alles funktioniert. Und ja, es gibt von der Community auch für für den Release Prozess 'n paar Docker Container, die ein paar von den Sachen abnehmen. Die kann man sich dann entweder forken oder den den Originalen benutzen oder sich da was selber bauen, einfach da die Automatisierung zu machen, dass da weniger Probleme sind. Aber so, das ist halt 'n langer Prozess mit sehr vielen Fragen. Und da, immer wenn ich eigentlich 'n Problem dazu hatte, habe ich innerhalb von 'n paar Stunden eine Antwort bekommen. Einfach weil da so viele Leute dran interessiert sind, dass die Sachen laufen und superhilfreich sind. Das hat sehr viel Spaß gemacht. Ja, und sonst ich freue mich jedes Jahr immer sehr über den den Deplications RFC, weil die PHP Mailing Liste hat ja einen schlecht, das schlechteren Ruf, dass es immer son bisschen, je nachdem, aus welcher Generation man ist. Und da nach 5, 6, 7 Jahren inaktivität bei mir persönlich zurückzukommen, war sehr cool zu sehen. Das sind ganzen Haufen junge Leute. Also ich würd sagen, die Hälfte der Leute, die am PHP Chor arbeiten, sind unter 30.
Dave: Oh, das
Jan: ist krass. Der Das
Dave: hätt ich nicht gedacht.
Volker: Vielleicht jetzt dieses Jahr weiß ich von 2 Leuten, dass die 30 geworden sind. Ja. Vielleicht ist es jetzt technisch gesehen sogar falsch. Aber ja. Also 1 der der Chorentwickler hat auch mal öffentlich, glaub ich, sogar gesagt, wie bist Du denn zu PHP gekommen? Wenn ja, jemand in der Uni hat mich gedärt, an der Sprache was zu fixen und dann dann hat's mich erwischt und jetzt mach ich's halt weiter.
Dave: Geil. Oh, das ist schöne Story.
Jan: Aber lass mich da ganz kurz einhaken, weil vielleicht weißt Du da tatsächlich mehr von, ich mein, das mit der Uni ist natürlich eine coole Geschichte, aber mich würd's wirklich interessieren, also was was heute junge Menschen noch so zu zu PHP bringt, ne, weil viele ja irgendwie doch bei type Script, Node, keine Ahnung, irgendwie hängenbleiben und kommen die über so Larawelle und Symphony oder was was was bringt die da?
Volker: Ja, Dave, Du wolltest
???: noch Ach
Dave: so, ne, ich wollte ich wollte aus meiner, also weil ich mich noch als Wobei ich hab ich hab ich hab heut, nee, gestern hab ich gelernt, dass ich nicht mehr zu den jungen Menschen zähle, weil junge Menschen nur bis 27 sind, da bin ich jetzt raus. Und aber ich wollte sagen, weil ich hatte ja auch in in meiner universitären Ausbildung hatte ich ja tatsächlich auch mit PHP zu tun. Also ich bin son bisschen gebrandmarkt. Liegt wahrscheinlich aber daran, weil's halt auch ältere Professoren sind, die das damals wirklich genutzt haben. Und ich musste damals sogar an Jumler muss ich sogar entwickeln. Also ich muss einfach so Open Source mäßig und also es hat mich zumindest son bisschen zu PHP gebracht.
Jan: Ja, aber Nee, hat's ja grad nicht, weil Du bist ja nicht hängen geblieben, weißt Du?
Dave: Nee, ja, so was Du meinst Du meinen? So, also Ja, das stimmt.
Jan: PHP Kontakt haben bestimmt super viele da draußen, aber dass sich Leute jetzt noch quasi neu dafür begeistern, auch so bis in den Chor irgendwie da da mitzumachen, das ist ja schon cool, richtig? Und wo kommt wo kommt diese dieser Schlag Menschen her?
Volker: Genau. Also das eine sind ja die PHP User, darum ging's jetzt ja nicht, sondern die die Leute, die dann wirklich im Corbass machen, dass es viele Leute, die so Hardcore Computer Science Mathe Kram machen und halt über Sprachentwicklung nachdenken und über so Ich ich hab mal 2 Jahre lang über Alexa und Parser nachgedacht und gebaut und die also Leute, die dann auch eher einen Mathe Background haben und dann halt rumgucken im im Internet, was gibt's denn so an Sprachen? Wo wo man irgendwie contributen kann, wo man irgendwie da Erfahrungen sammeln kann, wo man da Leute findet, die die die so ähnlich denken wie man selbst. Ich kann mir vorstellen, dass zum Beispiel in reinzukommen reinzukommen, weil das einfach alles Microsoft gehört, schwierig ist. Ich kann mir vorstellen, dass das bei anderen Sprachen halt ja, da große große Communities gibt, wo es nicht ganz einfach ist, da reinzukommen, wenn man sich da ausprobieren möchte auch. Und da ist PHP halt als Sprache, die ja den großen historischen Wert hat. Was was kommt denn PHP rein? Ja, was Leute halt haben wollen und bauen wollen. Und es schlägt halt eine Person vor und man kann da als Einzelperson sehr viel bewegen und machen, dass das 'n interessantes Ziel ist. Das ist zumindest so die Geschichte, die ich von von von den Leuten gehört hab, dass sie halt gesagt haben, ja, ich hab mich halt umgeguckt, wo man irgendwie was machen kann mit Programmiersprachendesign und PHP war da halt da und die Leute sind halt nett und umgänglich. Ja. Und man muss nicht irgendwie erst 10 NDAs unterschreiben und irgendwie sonst was tun.
Dave: Ja, aber und wollte ich grad sagen, also ich glaub dieser Impact den darf man auch nicht vernachlässigt, also weil ne, PHP ist ja so weit genutzt, dass man denkt, hey, wenn ich da 'n Change mache, das betrifft so viele Leute, das verbessert das Leben von so vielen Menschen. Wie geil ist das bitte? Also
Volker: Ja. Ist auf jeden Fall auch
Dave: noch mal 'n Faktor.
Volker: Also auch, was Du dir auf deine CO2 Bilanz schreiben kannst, wenn Du PHP in Prozent schneller machst, Ist ja ist ja schon 'n sehr großer Impact, den man da haben kann. Ja. Und jetzt es ist von den Skriptsprachen jetzt natürlich schon eine Sprache, die sehr schnell ist, aber auch der der Parser ist halt relativ offen. Und ein, ja, wenn man da die die Skills hat, kann man sich da schnell rein schnell reinbringen. Genau. Aber das sind dann auch Storys, die die erzählen die Leute immer besser als selber. Deswegen habe ich jetzt nicht versucht, von 1 Person die Storys nachzuerzählen, sondern son bisschen zusammenfassend gesagt, so, ja, viele Leute, die das während der, also während der Uni machen, deswegen sind die auch jetzt 'n bisschen jünger.
Jan: Okay. Abseits von diesen ganzen Sprachfeatures von Code Reviews, von den RFCs, Was also was gehört denn noch zu 'nem Release alles dazu für, weil das ja auch verantwortlich seid? Ich denk da so an Dokumentation, Webseite, Blogpost, Announcements. Ist alles was, was auch von der Community gemacht wird oder macht ihr das dann als Teil von dem Release Management? Was gehört noch dazu?
Volker: Genau. Also die Dokumentation macht das BRP Docks Team komplett eigenständig. Das sind 'n Haufen Volunteers, die und im Zweifel die Leute, die die Features bauen, sind natürlich auch dann interessiert, dass das irgendwie dokumentiert wird. Es ist aber meistens so, dass die Schnittstelle dafür eigentlich eher die Tests sind, die die Leute schreiben. Also wir haben ja dieses lustige PHPT Test Format, wo Du halt in das gleiche Datei 'n Stück Code reinschreibst und dann drunter, was da rauskommen soll. Also Basicly Snapshot Testing, aber halt das ruft halt die PHP Binary auf und führt dann 'n bisschen Code aus und was soll dann rauskommen? Und das ist eine ganz gute Kommunikationsschnittschnelle zum Dock Team und halt die RFCs, die die Leute schreiben, dass da halt schön beschrieben ist. Und dann packt es von da jemand auf die Doku. Genau, das ist das ist der Punkt. Marketing und Announcement technisch ist es so, dass die das Web PHP Repository, also die das Web PHP Repository, also da, wo die Webseite drin liegt, ist auch einfach in der PHP Organisation auf GitHub. Da gibt's dann für für jeden Release jemand, der mal anfängt zu sagen, hier ist mal die Seite und dann wird da diskutiert, kommentiert, an an dem an an dem polar request kollabiert oder an dem, wo wo die neue wo die neue Seite drin ist für für den Marketing Release. Da hatte ich jetzt nicht superviel damit zu tun. Was wir jetzt angefangen haben als Release Manager, PHP bootet auf auf Mastodon und jemand vom Social Media Team managt auch den LinkedIn Account, dass wir für jeden Release Candydate son bisschen die die coolsten Release Notes zusammengeschrieben haben, dass die Leute sich das nicht alles selber erarbeiten müssen. Haben die früher auch gemacht. Aber genau, ich hab dann in dem, es gibt ein Todetogether Depot im Ball, das liegt, glaub ich, noch bei Derrick und nicht mal im PHP Depot selber, wo dann halt noch 'n Pull Request hingeschickt hat mit, hier sind so meine 500 Characters für diesen Release. Einfach, dass die Leute da 'n bisschen weniger machen müssen. Aber das ist auch alles Volontiers und auch Sachen, wo ich auch sagen muss, hab ich als Release Manager auch nicht so viel mitzutun. Genau, ich ich ich merke jetzt, ich sah jetzt zum fünften Mal, so so viel ist es gar nicht. Das heißt, wenn Du da draußen Lust hast, das auch zu machen, kannst Du dafür nächstes Jahr ja mal gucken, so viel Arbeit ist es nicht, PHP 'n bisschen was zurückzugeben.
Jan: Also ich finde, da wäre noch eine meiner Fragen gewesen, so was dein Pitch wäre für den Nachfolger. Ob das eher so, komm und mach das oder renn, lauf so weit Du kannst und dreh dich nicht
Volker: Ja, weißt Du, ich frag mich in 2 Jahren noch mal. Nee, ich bin ich bin bis jetzt sehr happy. Also man, wenn
???: man sowieso Kontakt mit der PPP Community hat, lernt man halt 'n paar von den Call Leuten
Volker: noch 'n bisschen näher. Mit der PPP Community hat, lernt man halt 'n paar von den Call Leuten noch 'n bisschen näher kennen. Man lernt die Prozesse 'n bisschen kennen. Man versteht dann auch nachher noch mehr von der Sprache. Es ist natürlich auch 'n super einfacher Weg, auf Konferenzen eingeladen zu werden, weil hi, bin Release Manager, hier ist was neu in der Sprache. Ist jetzt kein ist jetzt kein superkomplizierter Talk. Da da eine Featureliste irgendwie noch 'n bisschen spaßig und mit 'n paar Backstories, die man so selber dann ja erlebt über das Jahr irgendwie zu zu verkaufen kann, dann auch Spaß machen. Was war bei mir jetzt auch ganz nett, da mal wieder son bisschen während das in in in die Conference Sachen einzusteigen und 'n bisschen rumzufahren und 'n paar User groups zu zu sehen und Leute kennenzulernen. Also es ist eher so, ja, 'n netter Weg da, mehr soziale Kontakte zu knüpfen und 'n bisschen da sein Wissen zu vertiefen, wenn wenn man da dran Lust hat oder wenn man da einfach zurückgeben möchte. Also es sind auch Leute, die noch nie 10 gemacht haben, Release Manager, das ist auch machbar.
???: Mhm. Mhm. Ich find
Dave: das Okay. Also ich find das so krass, ich weiß nicht, was dein Eindruck ist an der Stelle, Jan, aber ich ich find das so cool, wie Holstome so diese Community ist und PHP. Also ich hab ja richtig Lust bekommen, jetzt so 'n Teil der Community zu werden, weil Du sagst aber so, die sind alles total hilfsbereit, antworten schnell, der übernimmt das und so. Und ich find das krass, wie so ein großes Projekt mit mit verteilter Verantwortung mehr oder weniger auf den einzelnen Features so gut funktioniert. Also das also ihr habt ja paar Prozesse, aber auch kleine, ne, wie Du's auch manchmal gesagt hast. Und es funktioniert irgendwie sehr, sehr gut und das find ich also sehr beeindruckend und irgendwie das hab ich sehr, sehr glücklich gestimmt auch.
Volker: Es ist natürlich schon so, dass das Projekt durch sein Alter nicht mehr unbedingt in der Sturm- und Drangphase ist, wo wo die Leute irgend Also ne, in den technischen Diskussionen, wenn's dann aber wirklich 'n spezifisches Feature geht, da ist dann, würde ich sagen, auch mehr Technical Disussion als Hosomness. Und Technical Disussion ist manchmal auch sehr geagedd und da ist dann da da ist dann schon auch mal eine größere Menge an Emotionen auch in den Leuten, wenn man sich da über über über über Themen streitet. Aber das das Kernding ist einfach, dass die PHP Community ja jetzt vom vom vom Ruf der Sprachen schon nicht unbedingt als als die Beste dasteht. Ich meine andere Leute, also JavaScript hat da ja auch eine eine lange Geschichte von irgendwie in 6 Tagen entwickelt und sonst was und Python hat jetzt auch nicht unbedingt den besten Ruf, je nachdem wen man pflegt. Aber sowas bringt ja eine Community auch näher zusammen Und alle Leute, die jetzt an dem PHP Release in irgendeiner Form mitarbeiten, machen das ja, weil die mit PHP arbeiten oder die Sprache cool finden und halt das Beste für PHP wollen. Und sone gemeinsames Ziel bringt die Leute dann halt schnell zusammen. Also man muss sich ja nicht mögen, aber man kann ja sagen, ja, wir wollen ja alle irgendwie das das Beste für die Sprache. Aber man kann ja sagen, ja, wir wollen ja alle irgendwie das das Beste für die Sprache und dass es da weitergeht. Und das macht das dann halt sehr einfach, da auch schnell Kontakt aufzubauen.
Jan: Ja. Ich hab sone Theorie, ich ich glaube, die PHP Community ist deshalb so holesome, normal, wie auch immer, ja. Weil in in der PHP Community so räumliches Zusammenkommen tatsächlich immer noch eine Rolle spielt. Also es gibt viele Konferenzen, die schon Jahre und Jahrzehnte laufen. Volker hat eben über die User groups gesprochen, ja? Die PHP User groups, die ich so kenne, die gibt es auch schon seit Jahrzehnten, ja? Da ist irgendwie, weiß nicht, wir sind ja hier im Rhein Main Gebiet, Dave, so, ja? Also Du Du nicht mehr ganz so sehr wie ich. Aber so so die View JS User Group, die die kommt und geht so, ja? Die React User Group, die die kommt und geht. Aber die PHP User Group, die gibt's halt einfach schon also gefühlt seit immer so für mich, ja? Und ich mach das auch schon echt lange, ja? Und ich glaube, wie immer, wenn Du halt die Leute kennst und öfter mit denen zusammenkommst, dann ist halt so der der ganze Umgang irgendwie auch viel angenehmer so, ja? Und selbst wenn Du dann mit Leuten im Internet irgendwie kommunizierst und kollaborierst, die Du nicht kennst, hast Du halt schon wahrscheinlich eine viel höhere Empathie demgegenüber, weil Du denkst, na ja, die sind ja auch so wie die anderen, die ich auf Konferenzen, Meetups, User groups, bla bla bla kennengelernt hab so. Also so gerne wir alle remote und fettheit arbeiten, so dieses Zusammenkommen, das ist halt schon unglaublich hilfreich da.
Volker: Was für mich sehr cool war dieses Jahr, Jet Brands hat ja das 30 Jahre PHP Event gemacht und gesponsert. Auch megagool, ja. Und meine Firma ist 1 der 5 größten Sponsor Sponsor Sponsor der Foundation. Also klar, wir bauen auch 'n Tool, dass wir gern Firmen, die PHP machen, verkaufen würden, deren Anwendungen besser zu machen. Also wir haben auch 'n Interesse daran, dass das Ecosystem weiter funktioniert. Und wir machen halt auch eine PHP Extension, deswegen macht's auch Sinn, dass wir einen 'n Kernentwickler haben, der der der dement. Das ist das macht alles irgendwo Sinn. Aber dadurch durfte ich auch dahin und Chatbrands hat halt dann die ganzen zumindest die ganzen europäischen Chor Entwickler einmal zusammengebracht und die alle mal kennen zu lernen für für so eineinhalb Tage und da halt mal rumzuhängen in dem coolen Recording Studio, das Chat BrainStar in Amsterdam hat, wo die dann halt diese Show gemacht haben und dann ja inzwischen sind mit den Leuten zu chatten, haben es noch irgendwie mal rauszugehen. Das hat auch sehr viel geholfen, da halt mal die ganzen Gesichter gesehen zu haben jetzt. Grad von den von den Chorleuten, die mehr Zeh machen, kann ich jetzt halt auch noch nicht so viele. Und dann hat man sich einmal gesehen und dann ist Kommunikation und Empathie auch viel einfacher, wie Du gesagt hast.
Jan: Okay. Dann wär ich, glaub ich, hier fast mit allen meinen Fragen durch. Dave, hast Du noch eine Frage?
Dave: Yes. Ich bin ja son Zukunftstyp mit immer dem Blick nach vorne. Erst mal vielleicht persönlich zu dir, Du hast auch vorhin von 'nem Senior Release Manager gesprochen, der ja euch da auch noch unterstützt.
???: Mhm.
Dave: Ist das perspektivisch etwas, was Du dann auch in Zukunft übernehmen wirst oder willst? Wie wie sieht's da aus?
Volker: Sehe ich jetzt, also da haben sich eigentlich immer genug Leute gemeldet, wenn da jemand anders mehr Spaß dran hat, gern. Das ist, glaub ich, sehr wenig Arbeit. Wenn sollte sich da aus irgend 'nem Grund keiner finden, mach ich das natürlich gern. Mhm. Das ist, also wie gesagt, das ist echt nicht so viel Arbeit, den Leuten halt einmal den Prozess zu erklären und dann halt irgendwie da zu sein. Kann ich mir sehr gut vorstellen, das dann auch weiterzugeben, das Learning, das man da gemacht hat. Mhm.
Dave: Und wird es vielleicht darauf auslaufen, dass Du noch mal Release Manager wirst fürn späteres Release?
Volker: Das ist eine fantastische Frage, ob das legal ist. Also wahrscheinlich ist es das. Mir wär nicht bewusst, dass irgend 1 der PHP Release Manager das jemals zweimal gemacht hat. Deswegen wahrscheinlich nicht, einfach weil's keine historischen Präzedenz hat. Sollte sich mal irgendwann irgendwann nicht genug genug Leute melden, kann man sich das Andenken. Aber das ist, glaub ich, eine Frage, da muss ich erst mal gucken, was ich in 3 oder 5 Jahren dann so beruflich mach und wo ich dann da bin in meinem Leben. Es ist auch, glaube ich, wenn man irgendwie Familie und Frau und Kinder und und sonst was hat, eine andere Stresssituation, als wenn man das so als als Single in in Berlin irgendwie an dem Dienstag son bisschen auf Firmenzeit noch machen darf.
Dave: Safe, ja.
Volker: Ja. Genau.
Jan: Okay, dann meine Frage zum Schluss, wie immer meine Standardfrage. Volker, welche Frage haben wir dir nicht gestellt? Auf welches Thema, was Du mega vorbereitet wolltest, unbedingt drüber sprechen und jetzt hat dich niemand danach gefragt?
Volker: Ah, es gab natürlich, es gibt natürlich ein ein Thema über auf das ich vorbereitet war, über das ich sehr ungern sprechen möchte. Nein, was weiß ich? Ich weiß
Jan: nicht, ob das die Antwort
Dave: auf die Frage ist, aber schieß los. Jetzt
???: würde ich das
Volker: eigentlich hören. Das würde ich viel
Dave: lieber hören.
???: Genau. Also ich
Volker: dachte aber, das interessiere ich ja vielleicht auch. Es gibt ja son paar Memes, die sich irgendwie im PHP Subreddit oder in den Jahren zu PHP so gehalten haben mit, wir brauchen irgendwie Die Sprache muss komplett asynchron werden aus irgend 'nem Grund, weil das irgendwas schneller machen soll. Und wir brauchen Generics, weil sonst geht alles den Bach runter und irgendwie noch noch noch 2, 3 so so Memes, die die Leute wiederholen, wo ich mir immer nicht sicher bin, wie wie ernst das jemand meint oder ob das einfach nur was ist, was man irgendwie mal gelesen hat und was cool klingt oder was man dann damit machen will. Da war ich natürlich drauf vorbereitet zu sagen, warum hat der PHP Release das das nicht? Oder bekommen wir in PHP 9? Endlich wird endlich die Welt einfach besser und schneller. Genau, das sind so die Fragen, die dann die dann eigentlich öfter kommen, wo ich jetzt ganz happy war, dass wir nicht drüber gesprochen haben, muss ich sagen. Ich beantworte sie jetzt über, jetzt hab ich's natürlich gesagt, jetzt muss ich's auch beantworten. Es gibt ja grad einen großen RFC, wo wo jemand gesagt hat, hier, lass uns mal komplett PHP umbauen und irgendwie das komplett auf auf Essing First umbauen, der im Moment heiß diskutiert wird und jetzt auch sich in eine in eine Working Group auf 'nem extra Repo abgespalten hat. Was halt ja, meines Erachtens 'n wenig mit mit aktuellem PHP zu tun hat oder wo man halt wirklich viel Zeit und und Feingefühl braucht, das halt so in die Sprache reinzumachen, dass man die Sprache halt nicht kaputtmacht dabei. Weil ich glaub, da sind wir uns einig, dass es für eine für eine Sprache, die jetzt seit 30 Jahren existiert, können wir jetzt halt nicht sagen, ja, 9 ist alles kaputt. So baut's halt so. Das ist dann halt einfach, das muss dann halt eine andere Sprache sein. Das und das oder man muss das dann halt einschalten können oder sonst irgendwas. Und das Generics Ding ist was, wo zum Glück dann jetzt so Leute wie die PHP Foundation dann halt auch mal den Research machen und die Blogpost schreiben und da mal die technischen Fakten dann halt auch aufbereiten. Was cool ist, ist, dass wir da sone Organisation haben, dass das halt nicht alles irgendwelche semi informierten langen Reddit Diskussions mit mir wär's ja lieber, wenn x sind, sondern dass dann halt auch mal 'n paar Leute, die wirklich die Sprache sehr tief vom, wie sie implementiert ist, verstehen, sagen, hier sind die Probleme, die wir damit haben. Das ist, was wir vielleicht tun können. Das ist, was wir nicht tun können. Also da bin ich sehr happy damit, dass die Foundation einem da auch viel Kommunikationsarbeit abnimmt mit da hat man sich mal jemand hingesetzt und mal wirklich 'n Tag lang Research gemacht und dann sauberen Post dazu geschrieben.
???: Mhm.
Volker: Genau.
Jan: Dann hätte ich vielleicht noch eine allerletzte Frage, die ich immer Leuten stell, die mit PHP zu tun haben und sehr viel mehr über die Sprache und unter der Haube wissen als ich. Und zwar, irgendwann hat sich ja Failes Book son bisschen von PHP verabschiedet. Ja. Und so seinen eigenen, ich weiß nicht, ist das noch 'n Dialekt, was ihr da jetzt so davon oder gebaut? Und ich hab mich immer gefragt, wie die Chancen stehen, dass die irgendwann wieder zurückkommen. Weil auch node js hatte ja immer sone Abspaltung, ne, mit node und I o und irgendwann ist es wieder zusammen gelaufen. Und ich mein, jetzt ist das mit Facebook schon, weiß nicht, bestimmt schon Jahre Jahrzehnte? 10 Jahre her? Keine Ahnung. Glaubst Du, das passiert irgendwann, dass so jemand Großes wie Facebook wieder zurückkommt zu pur PHP? Mhm.
Volker: Genau. Also die haben ja dann HHPM beziehungsweise dann Hacklang entwickelt. Genau. Das ist ja auch, was Slack im Backend benutzt und was man an 'n paar anderen Firmen aus Mountain View oder sonst was nachsagt, dass es da vielleicht existieren könnte. Ja. Wird das werden die jemals wieder PHP machen? Witzigerweise, wenn man sich die letzten 3 bis 6 Monate auf auf diversen GitHub Repos anguckt, ohne da jetzt Namen nennen zu wollen, sind da contributions von oder sind da Leute, die wohl bei Facebook arbeiten, deutlich aktiver geworden und auch aus von Facebook IP Adressen irgendwie relativ viele Requests auf manche Sachen passiert? Also da scheint sich irgendwas zu tun. Spekulationen, da jetzt noch mehr zu machen, steht mir, glaube ich, nicht zu oder aber also ich kann's mir sehr gut vorstellen. Die viele der Gründe, die die Facebook damals hatte zu sagen, wir wollen da jetzt was Eigenes bauen und wir wollen da vorher wir wollen da jetzt was anderes machen, haben sich, glaube ich, soweit in PHP gelöst und das hat die Community einfach nachgebaut. Die haben natürlich garantiert 'n paar Performance Use Cases, wo's Sinn macht, noch eine PHP Extension zu haben. Aber vielleicht macht's halt mehr Sinn, nur eine PHP Extension zu haben, statt die komplette Sprache zu mänden. Ich weiß auch nicht, was jetzt bei wie bei Facebook die letzten 10 Jahre die Sprachentwicklung gegangen ist. Wenn's da Blogposts oder öffentliche Sachen gibt, kenne ich die nicht. Ich kann mir gut vorstellen, dass die jetzt auch in anderen Sprachen mehr machen oder sich da diversifiziert haben und dass es halt keinen Sinn macht, irgendwie 2, 3, 4 Leute oder wie viel auch immer zu bezahlen, nur die Programmiersprache weiterzuentwickeln. Wenn man da Und die andere Frage ist jetzt im im Age von AI Coating, wenn ich meine eigene Sprache entwickle, kann mir dann denn eine AI dabei helfen, die zu schreiben? Facebook ist ja auch sehr all in, was das Thema angeht. Also ich vermute, dass Sie da auch Struggles haben und ich kann mir gut vorstellen, dass für die zu sagen, wir machen jetzt wieder traditionelles PHP auch in der Richtung einen Vorteil hätte im Vergleich zu deren propetitärer Codebase.
Jan: Also das mit AI ist 'n superguter Punkt. Ich kam tatsächlich eher daran zu sagen, na ja, diese ganzen Gründe, die sie damals genannt haben oder zumindest so wie ich das noch präsent hab, ne, waren ja viel so diese ganze Typisierung und so Lambda Sachen und so was alles. Und wie Du schon sagst, einiges ist mittlerweile in PHP gelandet, anderes könnte man mit Extensions irgendwie selber nachreichen. Und da lohnt sich halt dieser Riesenaufwand da irgendwie noch. Aber ja. Ja. Interessant auf jeden Fall. Ich bin gespannt.
Volker: Ja. Bin gespannt. Also die die Leute, die noch am PHP Chor arbeiten, die mal bei Facebook waren, sind da auch schon länger nicht mehr. Und deswegen ist es da auch schwierig, dann mir jetzt was zu sagen. Und ich glaub, von offizieller Seite gibt's nix Werberspannendes zu wissen, natürlich.
Jan: Also Also falls es einfach nächstes oder übernächstes Jahr angekündigt wird, dass Facebook zurück auf PHP geht, dann sag ich jetzt mal, hört it here first, ja? Ja. Exklusiv Breaking News in der programmier.bar, so. Und falls das nicht passiert, haben wir nie drüber gesprochen. Oh, wir schneiden das aus. Sehr gut, nachträglich. Wunderbar. Dann haben wir noch unsere Kategorie für die Boah, das ist noch nicht. Oh, eine Sache.
Dave: Eine Sache, nur weil Du's grade erwähnt hast, Volker. Ich muss sagen, ich hab mir parallel einfach mal die PHP Memes angeschaut, die Du angesprochen hast. Das ist da ist wirklicher Feier dabei. Also Empfehlung geht raus an alle, ne, mit 'n bisschen Augenzwinkern, aber ist schon lustig.
Volker: Ja, ja, ich mein, das ist ja auch, also es ist Laaawell hat der PHP Community, glaube ich, insofern gutgetan, dass da halt 'n großer Influx von von jungen Leuten, die coole Sachen bauen wollen und wo's halt auch drum geht, erst mal 'n Business shippen, dann gucken, was die Codebase macht. Ist jetzt natürlich stimmt als auch so für nicht für alle liberale Leute, aber da halt da ist ja ein größerer Drive in der Community, Produkte zu bauen, coole Sachen zu machen, vorwärts zu kommen, schnell zu sein, da Spaß zu haben. Die haben viel gemacht, was PHPs Ruf auf Twitch angeht in in anderen Communitys, also so mit den mit den jungen, ich sag mal Reaction Youtubern und irgendwie Code den Code Twitschern, da irgendwie Brücken zu bauen und zu sagen, hey, guck mal, mit der Sprache kann man doch einfach schippen. Und das ist ja auch, was viele Leute, was was auch mich und andere Leute zu PHP gebracht hat vor vor vor vielen, vielen Jahren, dass wir gesagt haben, ich will einfach noch was bauen. Ist mir doch egal, was das für eine Sprache ist. Das tut nicht weh. Ich hab eine Webseite fertig, ist doch cool. Und dass son bisschen dieser dieser Spirit da irgendwie 'n bisschen weiterkommt, während jetzt irgendwie, ja, weiß ich nicht, Leute aus meiner Generation sagen, ja, es war ja auch nicht alles an Jammer schlecht, sagen halt andere Leute jetzt halt, ja, aber ich kann doch was bauen mit PHP, schneller vorwärts. Und dass wir uns das son bisschen behalten, ist ist schon cool. Damit kommt dann halt auch, dass Du durch 'n Haufen Inflaxt von jungen Leuten hast Du dann halt auch viel so Ich hab auf Twitter gehört, wenn PHP x nicht bekommt, stürzt dann. Und so, ja nee, das es läuft einfach alles noch. Die Sprache ist as a life as ever und das ist alles gut. Genau. Aber freut mich, dass dass man da noch 'n bisschen Spaß haben kann.
Jan: Dave hat auf alle Fälle seinen Spaß gehabt. Ja. Ja. Wunderbar. Dann versuch ich das jetzt einfach noch mal mit diesen Picks of the day.
???: Ich
Jan: weiß gar nicht, Dave, waren das jetzt schon deine, dass Du die PHP Memes irgendwie als Empfehlung für alle da draußen oder oder kommt da noch was? Alles soll
Dave: auch separat bitte verlinkt werden auf unserer Seite. Jedes einzelne Meme, alles gut ist, ey. Nein, natürlich nicht, Janusz. Ich bin ja wieder wie immer perfekt vorbereitet und hab mir nicht während der Folge überlegt, was ich erwähnen könnte.
Jan: Das würden wir nie tun, so was, deswegen präsentieren uns doch mal deinen Pick, den Du schon seit Wochen fertig hast.
Dave: Ja, selbstverständlich. Und zwar ist das diesmal eine Empfehlung für Leute, die eine Smartwatch haben. Ich weiß nicht, ob's für alle Smartwatches existiert oder nur für Apple Watch User, deswegen an der Stelle der Disclaimer. Und zwar weil ich das, hat Platz auf meinem Homescreen sogar auf der Uhr direkt gefunden. Und zwar ist das Stresswatch. Ich weiß nicht, ob euch da schon mal was sagt. Ist auf jeden Fall primär, glaub ich, dazu gedacht zu tracken, wie gestresst man ist und dann irgendwie im Überblick haben sollte, hey, okay, Du hast gut geschlafen, Du hast nicht so gut geschlafen. Grade ist irgendwie mega Tohuwabohu bei dir, indem es irgendwie deine Herzfrequenzvariabilität misst und abhängig davon erkennt, ob Du gestresst bist. Aber das ist eigentlich nicht der Grund, warum ich die benutze, Funfact, weil irgendwie, wie es immer sagt, dass ich überlastet bin, dass ich was mit mir Sorge Sorgen machen muss. Aber eigentlich will ich das nicht sehen. Ich möchte eigentlich hören, dass es mir supergut geht. Nee, was aber wirklich gut ist für alle, die sehr sportaffin sind, ich find es sehr cool, die deren Trainingsübersicht, die empfehle ich an der Stelle, die Trainingsübersicht dort, weil das richtig cool ist, Du siehst während der Trainingssession, wie deine Belastungsspitzen waren, wie lang Du in 'nem bestimmten Herzfrequenzbereich warst. Und das ist sehr schön aufgeschlüsselt und gibt dir eine geile Übersicht, grad wenn Du natürlich irgendwie dein Training 'n bisschen optimieren willst, wo Du sagst, hey, hier wollt ich jetzt besonders mich auspowern, einfach nur 20 Minuten Hardcore oder da wollt ich mal 'n bisschen lässiger angehen und das genau dann sehen kannst, in welchem Bereich Du dich befunden hast. Fand ich sehr schön als Übersicht. Und ja, ich hab ja son bisschen kleine lustige Gesichter auf meiner Uhr, das ist auch irgendwie ganz schön zu sehen. Fand ich auf jeden Fall sehr cool.
Jan: Da hab ich direkt eine Rückfrage zu. Also also ich kann mir schon vorstellen, dass Du von dieser Trainingsansicht sehr profitierst. Du machst ja noch mehr Sport
Dave: als ich. Genau. Und da und also dass das überhaupt geht, find ich krass, aber ja.
Jan: Aber gleichzeitig kenn ich dich ja, Du bist ja auch so, ja? Ja. Und ich kann mir vorstellen, wenn Du jetzt auf deiner Uhr immer siehst so, boah, grade bist Du voll gestresst, dass Du dir da denkst so, oh, ich ich ich muss weniger gestresst sein. Und dann stresst dich das noch mehr und dann kommst Du in son Stres Teufelskreis rein, ja? Und die Uhr triggert dich nur noch.
Dave: Ja, das, also ist auch eine reale Gefahr, die ich sehe tatsächlich. Ich hoffe, die bewahrheitet sich nicht. Wenn das jetzt über Wochen so ist, dann also dann mach ich die auch wieder weg so. Aber ja, ich ich hab schon auf jeden Fall die Benachrichtigung ausgestellt, das schon mal ganz gut, weil die sagt immer so, oh, Du bist grade sehr gestresst, pass mal auf auf dich.
???: Ja, und das
Jan: kam offensichtlich so oft, dass es dich gestresst hat. Ja. Also siehst siehst Du, was ich meine?
Dave: Ja, okay, vielleicht ist es schlechter Pick of the day, aber ich find, diese Trainingsansicht ist cool. Wahrscheinlich gibt's dafür auch bessere Apps, by the way.
Volker: Ja, wirst doch schön. Besser Daten haben als keine haben. Kannst Du dann ja immer noch entscheiden, was Du damit machst?
Dave: Genau. Genau. Also falls jemand auch eine bessere Empfehlung hat an alle, die grade zuhören, gerne mit bessere Tipps für für für son Trainingsapp.
Jan: Oder wenn ihr das nächste Mal bei uns zum Meet-up vorbeischaut, einfach Dave direkt mal ansprechen und fragen, wie gestresst der eigentlich grad ist.
Dave: Ja. Grad geht's tatsächlich. Grad grad bin ich im normalen Bereich, steht hier.
Jan: Ja. Wunderbar. Okay, cool. Volker, was hast Du am Start?
Volker: Genau. Ich hab mir jetzt kurz überlegt, als mach ich jetzt in 15 Minuten Monologe Woche online Silksong und dacht mir in Nein. Oh, ja bitte, bitte.
Dave: Ich hab's, oh, ich hab's auch. Ich hab's jetzt irgendwie vor vor 'nem Monat durchgespielt. Es ist so gut, es ist so gut.
Volker: Genau, aber ich glaub, das ist eine Discovery Journey, die die Leute selber machen können und die Ja, das stimmt. Ich red was über ich red über was anderes mit Computern. Und zwar, als ich mir so gedacht hab, was hab ich eigentlich so, wenn ich wenn wenn wenn jemand sagt, so sag mal irgendwas, was alle benutzen können, was irgendwie jetzt auch, wenn man kein PHP macht oder so Sinn macht, wenn man's mal braucht und davon zu wissen, cool ist, dass ist ist mir hyperfeinde in den Kopf gekommen. Hyperfeinde ist 'n Linux Commandlin Tool. Dem gibst Du 1, 2, 3 Argumente und der vergleicht dann, wie schnell die wie schnell die Sachen laufen. Und das ist, was Performancemessen angeht, das erste Mal, dass ich 'n Tool gefunden hab, das einfach out of the box alles richtig macht. Das es sagt nicht irgendwie, das ist 20 Prozent schneller oder langsamer als was anderes, sondern das sagt, das ist 1.1 Punkt 2 x schneller und nimmt dann diese ganze Ambiguität aus der Sprache raus, dass Du nicht sagst, so, was heißt jetzt 20 Prozent an 20 Prozent mehr und dann wieder 20 Prozent weniger ist ja auch falsch. Und das macht einfach 'n richtigen Satz, sodass man's immer korrekt kommuniziert. Das lässt das Ding zehnmal laufen, sagt dann, hier haben wir eine Standardabweichung. Das ist so das sind so die Errorbars, hier ist eine Unsicherheit drin. Du hast jetzt 2 Sachen verglichen, die sind einfach noch unsicher gegeneinander. Das macht jetzt nicht wirklich Sinn, dass Du dir da Gedanken drüber machst. So lass das einfach, hör auf da über die Performance nachzudenken. Das ist alles im Messfehler. Und macht sonst auch 'n ganzen Riesenhaufen Sachen wichtig, die super kompliziert sind. Und auch weil ich mich jetzt halt im mit PHP dann mit Patches beschäftigt hab, dass Leute sagen, hier guck mal, hier ist was schneller, ich hab's gemessen, hab ich da halt immer wieder gesehen, so, die Sachen messen ist halt echt schwierig. Und wenn man's dann selber einmal ausprobiert und misst und den Leuten dann sagt, so hier guck mal, ich hab 'n Tool benutzt, das dafür gemacht ist und damit gemessen, dann deine Änderung hat nichts, absolut nichts verändert, dann sagen die Leute immer erst, das kann ja gar nicht sein und nach dem Tag so, oh doch, ich hab einfach nur Zeit weggeschmissen, weil ich's nicht anständig angeguckt habe am Anfang. Und ja, da ist Hyperfallen mit Abstand mein mein Lieblingstool und ich bin so happy, dass ich das dass ich das entdeckt hab. Geil.
Jan: Ja. Cool. Also ich würd auch sagen, die die GitHub Repository Seite, wenn man's einfach nur dieses gif am Anfang mal anguckt, man sieht einfach instant, was es macht und wie das funktioniert. Das ist sehr gut sehr gut gemacht.
Volker: Und das ist auch, auch wenn man irgendwie an an Developer Experience oder an 'nem Terminal arbeitet, würde ich sagen, ist das 'n Tool, das man sich mal angucken sollte, einfach weil die wirklich sehr viel, was so Kommunikation Richtung Entwicklern angeht, richtig gemacht haben.
Jan: Wunderbar. Hyperfein, nehmen wir mit auf die Liste. Jan. Ich hab ich hab auch einen einen Pick dabei. Ach. Und zwar für die nicht mehr ganz so Jungen unter uns Dave vielleicht. Ja, das bin ich jetzt. Wer wer von euch erinnert sich noch an Command und Conquer?
Dave: Oh, ich. Ah, ich. All denke, dass sie liebt.
Jan: So, okay. Was war das beste Spiel in der Command and conquer Reihe?
Dave: Alarmstufe rot 2, oder?
Jan: So so ist es nämlich. Alarmstufe rot 2. Ich hab, weißt Du, wenn Du jetzt so Timberientsson oder so was geantwortet hast, dann wär's schwierig geworden Nein, aber
???: aber ich
Jan: Alarmstufe rot 2.
Dave: Ist aber, glaub ich, auch das Einzige, was ich gespielt habe tatsächlich. Aber also muss ja auch dann dementsprechend Standing haben. Okay.
Jan: Also Das ist wenn wenn ihr auch da draußen Command und Conquer gefeiert habt und gerne mal wieder Alarmstufe o 2, also Red Alert 2 spielen wollte. Es gibt jetzt einen Nachbau davon, aufbauend auf den Original Assets mit in Web Assembly, den ihr im Browser spielen könnt.
???: Das ist
Jan: Der nennt sich Chrono Divide. Verlinken wir auch direkt bei den Shownotes. Man braucht so eigentlich musst Du die Original Assets mitbringen, so weil Du darfst ja das Spiel nicht raub kopieren, also lad hier deine Assets hoch, damit wir's rendern können. Ist aber 'n Fallback Link hinterlegt. Wenn ihr sagt, ich hab die Assets grade nicht, kannst Du bitte aus dem Internet für mich laden, dann funktioniert das auch alles wunderbar. Und das Coole ist, es ist nicht nur 'n Nachbau von dem Spiel, sondern es ist einfach out of the box netzwerkfähig. So, also ihr könnt quasi Multiplayer Red Alert 2 jederzeit aus dem Browser heraus starten, so, ja? Damit hab ich euch hoffentlich allen das Wochenende gerettet, so.
Volker: Fantastisch. Und wie wie wie wie passend von der Zeit auch. Grad vor 2 Tagen hat hat hat 1 der der Realtime Strategy Youtuber eine viereinhalb Stunden Commonine Concord Retrospektive rausgebracht rausgebracht rausgebracht. Wo ich die die ich letzten, die ich jetzt noch geguckt hatte, wo ich mir dachte, ah, ich kann die Frage sogar beantworten, weil ich alle Spiele noch mal besprochen gehört habe. Geil.
Jan: Ja, also das mein mein Pick of the day. Ich werd das auch die Tage immer wieder auspacken und mit 'n paar Freunden zusammenspielen, weißt Du? Es ist einfach, es hat so viel richtig gemacht. Also es ist mir geht mir ganz oft so, ne, wenn ich so moderne Spiele angucke, denk ich so, also irgendwie hat doch, weiß ich nicht, Age of Empires 2 auch schon alles gehabt, so. Wieso muss ich da noch mehr verschiedene Currencies und Minispiele und Metasysteme und so was alles reinwerfen, so. Wir wir waren doch im Prinzip fertig mit dieser Spieleentwicklung, so. Keine keine Ahnung. So. Das mein mein Schlusswort hier zum zum Sonntag.
Volker: Ja, aber wir müssen Volker,
Dave: ach so, nein. Wir müssen was Wir
Volker: müssen aber wir müssen mal
Dave: den Silksong aufnehmen. Also es ist trotzdem Pick of the day. Also auch wenn Du's nur ganz kurz angeschnitten hast, aber sehr wichtig, dass jeder das mal gespielt hat. Jeder. Auch der keinen Kontakt zu Videospielen hat, ist es ist einfach 'n Mus play.
Jan: Ich muss sagen, ich hab das noch nie gespielt.
Dave: Ja, hol's nach an diesem Wochenende.
Jan: Nix, hollow Knight. Nee, ich muss am Wochenende command conren Conrenal.
Dave: Das war das Wochenende nach, zu Weihnachten, zu Weihnachten, direkte Zeit.
???: Bei mir
Volker: waren's nach 500 Stunden Hollow Knight und Speedrunning und sonst was waren's dann 7 Jahre langes Warten. Und auch, ja, auch der von von Dan Olzen, der Packs Vortrag zu zu Silk Posting ist auch 'n kultureller Meilenstein dieses des Jahres für mich, weil die Leute ja einfach in 7 Jahren sich sonst was ausgedacht haben zu dem Spiel. Ja, genau. Ja. Definitiv mal wert, sich's anzugucken.
Jan: 100 pro. Wunderbar. Diese Folge war's auf alle Fälle wert angehört zu werden. Volker, danke dir dafür. Danke für die Zeit. Danke auch für die Arbeit, die Du da reinsteckst. Sei ich auch als Youngjähriger PHP Nutzer bin auf alle Fälle super dankbar, dass es Leute gibt wie dich, die das tun und das weiter unterstützen und vorantreiben. Ich glaube, das halbe Internet da draußen ist dir auch dankbar.
Volker: Ich ich dank euch, hat Spaß gemacht. Schön, da drüber zu reden.
Jan: Ja, das ist schön, dass Du son bisschen aus dem Nähkästchen geplaudert hast und den Leuten mal erzählt hast, dass halt diese neuen Sprachenversionen nicht einfach irgendwie an Bäumen wachsen und vom Himmel fallen, sondern dass da halt auch viel Arbeit und Absprache und so weiter alles drin steckt. Ja, das muss muss ja auch mal erzählt werden. Cool. So. Sehr cool. Wir verabschieden uns von allen da draußen, die zugehört haben. Wenn ihr Feedback für uns habt, dann immer gerne an Podcast at Programmier Punkt bar oder ihr schaut mal bei uns auf dem
???: Discord Server vorbei oder schreibt uns einfach auf den diversen Social Media Kanälen, wie ihr uns findet. Ansonsten sagen wir
Jan: tschau tschau und Social Media Kanälen, wie wir uns findet. Ansonsten sagen wir tschau tschau und bis nächste Woche wieder. Bis denn.
???: Tschüssi. Tschau.

PHP 8.5 mit Volker Dusch

Shownotes

Picks of the Day

Chrono Divide

Hollow Knight: Silksong

StressWatch

hyperfine

Speaker Info

Volker Dusch