Spoiler: Nein, keine Angst - das wird hier kein Abgesang 
In letzter Zeit sind vermehrt Leute an mich rangetreten, die mich gefragt haben, wie ich mir die Weiterentwicklung von ESPuino so vorstelle. Dazu möchte ich nun mal was schreiben, im Endeffekt jedoch auch zu einer Diskussion einladen.
Für meinen Teil sieht es so aus, dass ich viel in Bereitstellung und auch Support von Hardware eingebunden bin. Das läuft natürlich hinter den Kulissen ab, so dass das nicht für jedermann transparent ist. Zusätzlich kommen noch Neuentwicklungen dazu - das bringt auch immer viel Arbeit zum Recherchieren mit sich. Und dann muss das Ganze auch designed und bestellt werden. Letztlich kommt noch mehr oder weniger viel Löten drauf und halt Testen. Mit allem zusammen verbringe ich nicht selten komplette Abende. Alles in allem kann ich sagen, dass es nahezu keinen Tag im Jahr gibt, wo ich nicht irgendeinen Support für ESPuino gebe - und sei es nur per PN.
Daran habe ich durchaus Spaß - klar - weil sonst würde ich das auch nicht machen. Aber letztlich bedeutet das natürlich, dass meine Zeit für Softwareentwicklung ziemlich begrenzt ist. Und wenn nicht, dann gibt es auch einfach Tage, wo ich mal einfach nix mache. Im Gegenzug gibt es jedoch, und darüber freue ich mich auch, Entwickler, die an ESPuino weiterentwickeln. Sie stellen den Code dann freundlicherweise als Pull Request zur Verfügung und es ist an mir, diesen Code dann zu testen.
Probleme:
a) Ich habe zum Testen nicht immer Zeit/Lust.
b) Durch die vielen Features, die ESPuino inzwischen besitzt, sind komplette Tests gar nicht mehr möglich. Also ob sich das kompilieren lässt ist eine Sache - aber ich meine ob das jetzt fachlich alles passt. Da muss ich ganz klar sagen: Ich habe weder Zeit noch Lust, da immer alles durchzuprobieren. Speziell das Feature PAUSE_WHEN_RFID_REMOVED kommt mir hier mit DONT_ACCEPT_SAME_RFID_TWICE in den Sinn.
c) Zu manchen Sachen habe ich gar nicht die Hardware und da es abseits dessen ist, wofür ich ESPuino so nutze (das Projekt ist für mich natürlich auch gutes Stück weit Selbstnutzen), winke ich das durch, wenn es formellen Ansprüchen genügt und kompilierbar ist. Also letztlich sind da immer mal wieder Features dabei, die für mich selbst keinen Nutzen haben. Was an sich ja erstmal nicht schlimm ist, aber grundsätzlich ist es nicht gut, wenn es zunehmend Code gibt, für den sich niemand verantwortlich fühlt. Letztlich komme ich damit wieder auf Punkt a zurück, weil wenn ich für ein Feature selbst so gar keine Verwendung habe, dann habe ich so gewisse Motivationsprobleme, dafür Zeit aufzuwenden .
Alles in allem kann ich sagen, dass mir das im „Forum nebenan“ immer so ein bisschen missfallen hat, dass es so viele Forks gibt, weil letztlich macht’s das Ganze undurchsichtig. Ich war daher bisher bestrebt, die ganze Funktionalität aufzunehmen - da wollte ich auch niemand, der sich Arbeit gemacht hat, vor den Kopf stoßen. Auch irgendwie in der Hoffnung, dass wir damit mittelfristig mal „durch“ sind damit und dann erstmal eine Phase der „Stabilisierung“ einkehrt. Aber da weiterhin neue Features bereitgestellt werden (was ja auch schön ist, da es zeigt, dass das Projekt lebt!), muss das aus meiner Sicht ein Stück weit reglementiert werden.
Drei Vorschläge, die mir gut gefallen haben, möchte ich an dieser Stelle aufgreifen:
a) Entwickler, die beabsichtigen, ein neues Feature bereitzustellen, kündigen hier im Forum das zunächst an. Dann kann man drüber diskutieren, ob das einen gewissen Konsens hat. Weil wenn es nur 2-3 Leuten dient, dann muss das aus meiner Sicht nicht in den Hauptzweig rein. Heißt: Gibt es keine Diskussion und ich erachte es als nicht wichtig, dann wird es künftig nicht mehr aufgenommen.
b) Es sollte einen neuen Branch „dev“ geben, in den neue Features erstmal aufgenommen werden. Dort können sie erstmal besser getestet werden, ehe man das auf die Allgemeinheit loslässt.
c) Features/Baustellen auflisten, bei denen ich persönlich Arbeit sehe und die sich ein Entwickler schnappen könnte. Da würde mir bestimmt bissl was einfallen
Es wurde auch vorgeschlagen, dass es vielleicht einen Zweig gibt, auf den auch andere Personen Schreibrecht haben sollen. Da muss ich zugeben, dass ich mich damit nicht so ganz anfreunden kann, da ich gerne den Überblick behalten möchte. Denn diesen würde ich damit auf jeden Fall verlieren.
An dieser Stelle auch nochmal Dinge, die mir nicht gefallen:
a) (Komplexe) PRs, zu denen es keine Beschreibung gibt. Beschreibung speziell im Sinne, welcher konkrete Nutzen zu erwarten ist. Da rede ich insbesondere nicht von neuen Funktionen, sondern von Dingen, die den Bestandscode ändern.
b) PRs, wegen denen ich gefühlt 15-20 Mails pro Tag kriege. @Entwickler: Lasst euch Zeit, ich sitze hier nicht auf glühenden Kohlen.
c) Wenn ich hier zu Diskussionen aufrufe und es entsteht keine. Oder zumindest mal nur eine, an der sich nur ganz wenig Leute beteiligen - üblicherweise der „harte Kern“ hier. Weil letztlich will ich damit auch anderen Leuten die Möglichkeit geben, hier mitzubestimmen. Merke: Ich will hier gar nicht alles bestimmen oder einen auf „König“ machen. Mir geht es mehr darum, einen Konsens zu erzielen, an dem möglichst viele Leute Spaß haben.
Insgesamt wird das vermutlich dazu führen, dass es vermehrt Forks geben wird. Das muss dann aber vielleicht einfach auch so sein. Letztlich möchte das aber auch gar nicht alles alleine entscheiden. Insofern erscheint mir der Punkt, dass man das hier im Forum diskutiert, als ein guter Zwischenweg. Das setzt allerdings voraus, dass hier auch eine Diskussion stattfindet.
Audrücklich NICHTS dagegen habe ich, wenn ein Entwickler ein Feature zeigt/beschreibt und dabei auf das eigene Repository verweist. Auch sowas hatten wir schon und über PRs oder Cherry-Picking meinerseits, hat es dann, nachdem Interesse bekundet wurde, seinen Weg in meinen Hauptzweig gefunden.
Gut. Dann hoffe ich mal, dass ich niemand vergraule mit meinen Aussagen.
Dann diskutiert mal .
