Core-Entwicklung zu schnell?

[apollon77]

Hi liebe Entwickler Gemeinde,

ich wollte mal ein Thema zur Diskussion stellen, von dem ich heute in einem Thread etwas überrascht war. Ich würde das daher gern besser verstehen bzw. mich/uns als Core-Dev-Gruppe würden dazu gern mehr Meinungen interessieren.

@jey-cee sagte in Ein Jahr neigt sich dem Ende (2021):

Letztlich bin ich zu dem Schluss gekommen das ich mich weiterhin um meine Adapter kümmere, aber wohl keine neuen mehr Entwickle. Es ist ohnehin so das die Entwicklung im Core von ioBroker so schnell, Umfangreich und schwach Dokumentiert ist, das ich mich hier Abgehängt fühle.
Immer wieder kommen (neue) Themen auf die man Plötzlich beachten muss, auf Dauer ist das ziemlich anstrengend.

@eisbaeeer sagte in Ein Jahr neigt sich dem Ende (2021):

Ich habe schon länger keinen neuen Adapter mehr gebaut, weil auch ich finde, dass die Core Entwicklung zu schnell voran geht. Alleine die Anpassungen der vorhandenen Adapter nimmt dann viel Zeit in Anspruch. Zu aufwendig mit repos testing, produktiv, usw. Danach alles noch mit npm publishen. Hobby Programmierern, und zu denen zähle ich mich bezüglich Javascript, macht es das schwer.

Der js-controller ist die zentrale Komponente und genau hier haben wir die Herausforderung die Anforderungen von mehreren Zielgruppen unter einen Hut zu bringen:

• Adapter-Entwickler wollen am liebsten alles dokumentiert und convenient APIs ohne lästige "Historie" haben
• Visu- und "externe Device/typedetector Adapter" (zB iot) und deren Entwickler müssen sich auf Datentypen, Rollen u.ä. verlassen können damit Sie Ihren Job so convenient wie möglich für den User machen können
• User wollen mit dem ganzen Technik-Kram nix zu tun haben und es darf einfach nie abstürzen und eigene Skripte sollen mega simpel gehen
• Admin versucht die ganze Konfiguration (die teilweise "weil's halt geht" mega komplex sein kann) generisch unter einen Hut zu bringen
• ... (und ich hab bestimmt noch viel vergessen)

Wir als Core-Entwickler (@Bluefox, @AlCalzone, @foxriver76 und ich) bzw. wir zusammen als Entwickler-Community sollten hier, meiner Meinung nach, das Ziel haben eine Balance zu finden um ein konsistentes, interoperables und für "alle" sinnvoll nutzbares System zu schaffen. Dazu gehört auch Versäumnisse der Vergangenheit und zu schief gewachsene Zöpfe auch mal abschneiden zu können - mit maximal möglicher Rückwärts-Kompatibilität. Wir arbeiten beim js-controller vollständig über GitHub Issues und Projekte für alle Tasks. Und ein Großteil unserer Arbeit hat mit der Adapter-Entwicklung nichts wirklich zu tun sondern optimiert interne Prozesse im js-controller an sich oder betrifft systemweite Features.

Wenn ich es richtig interpretiere, so ist die Hauptkritik nicht die "Entwicklungsgeschwindigkeit" des Cores, sondern die "Deprecations" und "Checks" die dafür sorgen sollen das semantische und logische Datenstrukturen sinnvoll sind. Korrekt?

Es ist korrekt, dass früher nie geprüft wurde, das die Daten, die in einen State geschrieben wurden, zum im Objekt angegeben Typ stimmen; oder das ein Read-only State nicht beschrieben werden darf mit ack=false. Das hat alles Probleme an irgendeiner Stelle verursacht die gemeldet wurden. Um sicher zu gehen haben wir uns entschieden es nicht zu verhindern sondern erstmal nur zu loggen. Ganz im Zeichen der Backward compatibility.

Und ich bin ehrlich: Als wir diese Checks eingebaut haben, haben wir eigentlich mit keinen großen Problemen gerechnet, da diese Themen auch schon vorher in unseren Augen nach "common sense" sehr eindeutig waren. Wir waren sehr überrascht!

Von daher wäre es sehr interessant zu wissen was denn die eigentlichen Themen sind die "zu schnell" sind und euch "abhängen"?. Ist es "nur" das eben genannte? Oder welche andere Entwicklungen sind "zu schnell"? Sehen das andere Entwickler ebenso?

Wenn es "nur" das ist, dann frage ich in die Runde, ob jemand bessere Ideen hat, wie der Adapter-Entwickler solche Dinge mitbekommen soll. Debug Log lesen die meistens Devs nicht (vllt. es sei denn Sie arbeiten aktiv am Adapter) und viele Fälle kommen erst "in the wild" überhaupt zustande. Aber Debug Log hat kein User an.
Auch haben wir denke ich die relevanten Checks drin (Controller 4.0 demnächst bringt nur noch den Check das ein default Wert auch den richtigen Datentyp haben sollte, der schon in js-controller 3.x geloggt wurde; jetzt klarer dargestellt das es das ist) ...

Das Dilemma was jetzt entsteht ist folgendes: Wenn wir nicht aufräumen bzw. deprecaten werden wir einige (valide) Anforderungen nie erfüllen können. Visualisierungen werden beispielsweise nicht automatisiert sinnvolle Dinge für die User tun können oder die Visu-Entwickler müssen einiges mehr Aufwand erbringen, weil Sie sich auf "nichts" verlassen können. Oder (meist nicht so programmier-erfahrene) Endnutzer müssen in Ihre JavaScript-Skripte Fehlerhandling einbauen, damit sie alle Eventualitäten behandeln können, die Ihnen die Adapter entgegenwerfen.

Und zu guter letzt verstehe ich diese Frage/Unsicherheit in Bezug auf den Aufwand für "Bestandsadapter", aber ich sehe den Zusammenhang noch nicht für neue Adapter? Wenn man dort von vorn herein sauber arbeitet, dann ist das doch gar kein Thema. Oder übersehe ich was?

Danke für Eure Infos und Meinungen zum Thema.

Ingo F

[UncleSam]

Auch wenn ich der erste bin, der antwortet, soll das nicht heissen, dass meine Meinung wichtiger ist als die meiner Nachredner.

Es ist schon etwas dran, dass das Leben für Adapter Entwickler nicht ganz einfach ist. In der Vergangenheit wurden oft neue Features in js-controller und vor allem Admin entwickelt, ohne dass den Adapter Entwicklern frühzeitig klar kommuniziert wurde, was das für Auswirkungen hat. (Ich spreche hier nicht über die Objekt-Warnungen)

Seit über einem Jahr habe ich mir auf die Fahne geschrieben, die Adapter-Entwicklung und -Pflege zu vereinfachen und habe zusammen mit verschiedenen von euch schon einiges erreichen können:

• ioBroker Entwickler Portal
• dev-server
• Weblate für Übersetzungen
• adapter-dev
• neue Features im Adapter Creator

und im Moment arbeiten wir in einem Team an der komplett überarbeiteten Entwickler-Doku.

Beruflich wie auch bei ioBroker bin ich davon überzeugt, dass nur gutes Tooling zu guter Software führen kann. Und das war in der Vergangenheit schon ein grösseres Problem bei ioBroker. Das soll jetzt nicht eine Kritik am Core Team sein, sondern an uns allen: wir alle können dazu beitragen, das Ökosystem für uns besser zu machen.

Allerdings an einem Punkt darf das Core Team sich schon noch verbessern (wobei es schon grosse Fortschritte gab): die Kommunikation.

Ich weiss, ich bin auf keine Gegenliebe gestossen als ich vorgeschlagen habe, dass wir keine neue js-controller-Version veröffentlichen, bevor wir die Dokumentation nicht aktualisiert haben. Aber ein solcher Schritt wäre wirklich mal nötig um das Leben von "Teilzeitentwicklern" (und das sind ja die meisten von uns ) zu vereinfachen. Gewisse Diskussionen auf Telegram (z.B. mit @jogibear9988) haben schon gezeigt, dass vieles schlecht und gewisses sogar falsch dokumentiert ist.

Setzen wir uns alle doch zum Ziel für's 2022, dass wir noch besser kommunizieren und wir versuchen, unser Leben als Entwickler noch einfacher zu machen. Dann macht es nämlich auch weiterhin Spass, neue und alte Adapter (weiter) zu entwickeln!

[mickym]

@apollon77 Na ja ich bin kein Entwickler, aber das was sowohl an Checks mit dem JS Adapter, also auch an Usability mit dem Admin 5 gemacht wurde, lässt mich zweifeln, ob das alles so durchdacht war und die Community, die an diesen Entscheidungen beteiligt war - groß genug war.

Inzwischen sind meines Erachtens nach einem halben Jahr die großen Kritikpunkte an der Oberfläche, als auch bei den Checks nicht behoben und ich bin auch nicht der Meinung, dass was früher flexibel ohne Überprüfungen ging sich nun in ein Korsett pressen lässt. Man hätte Einschränkungen und Checks auf Adapterebene einführen können, aber nicht auf diese globale Art. Das hätte auch den Entwicklern ggf. Zeit gelassen oder die ggf. sowas ganz zu ignorieren.

Ein mqtt- Adapter, der ja gar nie berücksichtigt wurde, wird sich nie in das neue Schema mit Geräten, Channels und States pressen lassen, weil jede Hierarchieebene sowohl Werte enthalten kann und diese Unterscheidung einfach nicht sinnvoll ist. Ich kann auch jederzeit ein Hierarchieebene unter einen State publishen. Was soll das also - es wird nie funktionieren, weil das Konzept das mqtt verfolgt ein anderes ist und dann kann man den Adapter nicht mehr nutzen. Ich kann zwar nun Datenpunkte erstellen, aber auch nur nach diesem Schema. Veröffentliche ich eine andere Instanz mit dem mqtt-Adapter sind mir die Anzahl an roten und fehlerhaften Meldungen im Log gewiss - ich mache es nicht mehr.
Ich bin nach wie vor der Meinung ,dass man das auf Adapterebene entscheiden muss und nicht auf globaler Ebene, ob man diese Strukturen, Checks etc. will oder braucht.
Auch die Einschränkungen unter userdata ist in meinen Augen sinnfrei und macht Dinge, die früher zum Beispiel von Datenpunkten mit NodeRed nur mit x Zusatzverrenkungen möglich.

Mein größter Kritikpunkt auch als Nichtentwickler sind diese globalen Einschränkungen - zudem ich in meiner ganzen beruflichen IT-Karriere immer die Erfahrung gemacht habe - erst beschränken und dann ggf. aufmachen, aber nicht umgekehrt.

Ein System, dass für alle nutzbar sein soll, muss auch eine gewisse Vielfalt zulassen und sich darauf beschränken, wo es sinnvoll ist.

Na egal - ich bin kein Entwickler und wahrscheinlich ist mein Kommentar als User eher unangebracht. Aber gibt ja Mods, die das wieder löschen können.

[Jey Cee]

Es war zwar nicht mein Plan eine Diskussion an zu stoßen, aber ich dachte mir schon das es eine gibt.

Hier mal meine Punkte:

• die schnelle Entwicklung ist nicht per se das Problem, sondern das Funktionen eben mal schnell implementiert werden ohne Plan. Also ohne den Tatsächlichen bedarf zu ermitteln und mal mit anderen Entwicklern darüber zu sprechen. Dann wird die Funktion ins Stable gebracht, oft undokumentiert, wird nur für einen Adapter verwendet und wird dann irgendwann entdeckt. Im Besten Fall erfüllt sie die Anforderungen, im Schlechtesten nicht und es wird was eigenes gebaut.
  Dann wird die Funktion irgendwann unbemerkt immer Häufiger genutzt, aber irgendwann werden immer mehr Unzulänglichkeiten sichtbar und die Funktion muss angepasst werden. Dadurch das die Funktion dann in zig Adaptern so genutzt wird, muss sie entweder Kompatibel bleiben oder alle Adapter müssen angepasst werden.
• das andere sind Funktionen die eigentlich ein Zentraler Bestandteil sein sollten, müssen vom Adapter Entwickler selber gebaut werden. Mal so ein Beispiel: Das löschen von Objekten mit samt darunter liegenden Objekten. Gibt es diese Funktion mittlerweile?
• Generell fehlt Gefühlt oft der Weitblick durch welchen sich ungünstige oder unnötige Entwicklungen vermeiden lassen würden. Stichwort Gerätemanager: Wir wissen der Bedarf ist da, es ist klar das es Sinn macht und über kurz oder lang wird es ihn geben. Aktuell findet sich niemand der in Baut, aber über viele Technische Grundlagen haben wir gesprochen. Daraus könnte man locker Vorgaben für Adapter ableiten die das Handling schon mal vereinheitlichen und eine Schnittstelle bereit stellen. So hätte man gleich von Anfang an schon ein paar Adapter die Kompatibel sind und auch Bestandsadapter könnten im Vorfeld ohne Stress angepasst werden.
  Das würde auch unserem Langfristigen Ziel die Adapterkonfiguration von Überflüssigem Balast zu befreien entgegenkommen.
• Konsistenz: Ich habe immer versucht mich an die Vorgaben zu halten, deswegen hab ich auch immer in die Doku bezüglich Objekten und Rollen geschaut. Irgendwann hieß es dann, was ich mache steht so nicht in der Doku.
  Richtig das stand so nicht in der Englischen Doku, aber in Deutschen eben schon.
  Wenn man Glück hat erwischt man die richtige Quelle, aber man weis nie ob es die richtige ist.
• Das was im Core passiert verstehe ich zum Teil schon gar nicht mehr und die Zusammenhänge zwischen den Modulen sind nur noch Schwer Nachvollziehbar. Das macht eine Mitarbeit unmöglich und erschwert das Verständnis. Anfangs konnte ich noch viel aus dem Code heraus lesen, inzwischen versuche ich das schon gar nicht mehr.
  Und das setzt sich bei der Adapterentwicklung fort, viele Zusammenhänge erschließen sich einfach nicht und man irrt durch einen Dschungel.

@apollon77 sagte in Core-Entwicklung zu schnell?:

Dazu gehört auch Versäumnisse der Vergangenheit und zu schief gewachsene Zöpfe auch mal abschneiden zu können - mit maximal möglicher Rückwärts-Kompatibilität.

Macht nur keinen Sinn wenn man den selben Blödsinn weiterhin machen kann.
Wir gehen jetzt mal von dem aus wie bisher gearbeitet wird: Ein Entwickler sucht sich einen Adapter als Beispiel, weil da die Funktion drin ist die er braucht.
Anhand von diesem Beispiel erstellt er seinen Adapter, alles cool das Teil läuft.
Nachdem er fertig ist will er den Adapter ins offizielle Repo bringen, dann kommt das review und das Böse erwachen. "Sorry was du da gemacht hast ist leider veraltet und kann so nicht mehr Akzeptiert werden"
Konsequenz, ein erheblicher Teil muss Umgeschrieben werden. Das macht man ein- oder zweimal, aber irgendwann hat man keine Lust mehr.

Hier wäre es viel besser mit der Kompatibilität zu brechen, dann passiert sowas seltener. Wenn jemand ganz viel Bock hat Baut er eine Prüfung in den Core die die Kompatibilität nur für alte Adapter erhält und bei neuen einen Fehler wirft.

@apollon77 sagte in Core-Entwicklung zu schnell?:

Wenn ich es richtig interpretiere, so ist die Hauptkritik nicht die "Entwicklungsgeschwindigkeit" des Cores, sondern die "Deprecations" und "Checks" die dafür sorgen sollen das semantische und logische Datenstrukturen sinnvoll sind. Korrekt?

Nicht für mich, denn ich bin ein Befürworter davon. Wie das ganze gelaufen ist war etwas Unglücklich, weil es zu viel Unruhe und Fragezeichen geführt hat. Da war die Kommunikation im Vorfeld mit den Adapter Entwicklern nicht ausreichend oder hat nicht richtig Funktioniert.

@apollon77 sagte in Core-Entwicklung zu schnell?:

Und zu guter letzt verstehe ich diese Frage/Unsicherheit in Bezug auf den Aufwand für "Bestandsadapter", aber ich sehe den Zusammenhang noch nicht für neue Adapter? Wenn man dort von vorn herein sauber arbeitet, dann ist das doch gar kein Thema. Oder übersehe ich was?

Ist das so? Es gibt doch gar keine Garantie dafür das man Sauber Arbeitet (siehe Konsistenz & Rückwärts-Kompatibilität). Und Rückblickend betrachtet gibt es keinen Grund an zu nehmen das nicht Plötzlich Themen auf der Agenda stehen, die Anpassungsarbeit erfordern. Klar ein Break in form von Admin 2 auf 3 ist selten, im Idealfall passiert das nie.
Aber so Sachen wie die Objekt und Typ Prüfung sind ein Resultat dessen das es vorher nie geprüft wurde und sowas kann doch immer wieder kommen.
Wer was anderes behauptet ist Naiv.

Und on Top kommt ja noch der Umstand das nicht nur ioBroker Weiterentwickelt wird sondern auch auf der anderen Seite des Adapters, also das was der Adapter mit ioBroker verbindet. Auch das kann einen erheblichen Aufwand bedeuten.
(Als Beispiele sehe ich hier Zigbee2MQTT und deConz, welche auch ständig Updates bekommen)

@unclesam sagte in Core-Entwicklung zu schnell?:

Ich weiss, ich bin auf keine Gegenliebe gestossen als ich vorgeschlagen habe, dass wir keine neue js-controller-Version veröffentlichen, bevor wir die Dokumentation nicht aktualisiert haben.

Ich finde den Vorschlag immer noch gut.

[simatec]

Grundsätzlich kann ich die Diskussion auf der einen Seite verstehen, auf der anderen Seite aber auch nicht.

Wo ich absolut der gleichen Meinung bin, ist das Thema Doku.
Hier ist aber glaube ich jedem Dev und vor allem dem Core Team klar, dass hier Nachholbedarf besteht.

Was die Geschwindigkeit der Entwicklung von iobroker angeht, sehe ich eher die Qualität und den unermüdlichen Einsatz des Core Teams und der Entwickler.

Das hier nicht informiert wird und keine Transparenz da ist, kann ich so nicht bestätigen.

Klar ist hier ein regelmäßiges Verfolgen des Geschehens im Core Bereich auch sinnvoll, aber Informationen kommen hier definitiv sehr zeitnahe und transparent.

Ein ganz wichtiger Bestandteil sind hier inzwischen auch die Dev Meetings geworden, in denen sehr vielen Informationen geteilt werden.

Auch wenn ich selber nicht immer Themen habe, versuche ich immer mir einmal im Monat die 2 Stunden Zeit zu nehmen und bekomme dafür sehr viel wichtigen Input.

Alles im allem sollte man 2022 nutzen, um die Dokumentation im Dev als auch im Userbereich grundlegend zu überarbeiten und für Dev‘s transparenter und für User verständlicher zu gestalten.

Und allen Entwicklern, die sich hier teilweise zu wenig informiert fühlen kann ich nur aus meiner ganz persönlichen Sicht, zur Teilnahme an den Dev Meetings raten.

[Eisbaeeer]

@mickym Warum sollten User Kommentare unangebracht sein? Ich als Adapterentwickler lebe von Usern. Ohne User gäbe es keine Adapter! Und deine Sicht ist mindestens genauso wichtig. Denn die Adapter sind für die User.

@apollon77 Mal meine Sicht. Ich habe nicht wirklich viel Adapter im Vergleich zu anderen Entwicklern. Die Anzahl der Installationen liegen zwischen 100 und 1500 pro Adapter. Trotz alledem bekomme ich über die Github Issues natürlich auch Rückmeldungen, die sich mit den Anmerkungen von mickym decken. Warnings in Logs und Adapter die dann einfach nicht mehr funktionieren wie letztlich der Alpha2 Adapter. Um den Leuten dann zu helfen, muss man sich dann die Zeit nehmen und meist ist es genau dann ungünstig. Sicher kann man jetzt sagen, ist schon lange bekannt, hätte man gleich machen können, warum wartet man, bis es knallt, etc.
Für mich gesprochen ist iobroker nicht mein Beruf, nicht mein Main-Project, sondern nur ein "Hobby". Was mich auch noch nervt, sind die Github bots, die mir dann sagen, was ich noch implementieren soll ("please your adapter to ioBroker.discovery" oder "Update stable version in repo from ... to ..." oder "implement discovery for alpha2", etc.). Ich verstehe, dass bei der Anzahl von Adaptern das ganze mit bots einfacher ist. Stört mich halt, weil unpersönlich. Ich habe jetzt auch nicht die Zeit und Lust, mich in allen Foren von Neuerungen selbst zu informieren. Warum soll das eine Holschuld sein? Ich sehe das eher als Bringschuld. Eventuell gibt es ja schon announces diesbezüglich, dann sind die aber an mir vorbeigegangen. Schön wäre dann auch eine Hilfestellung bei Änderungen. Bei Änderungen sollte auch eine Risikoanalyse erstellt werden, was passiert wenn wir dies und das ändern, wie können wir die betroffenen Entwickler unterstützen, falls der Adapter dem Entwickler um die Ohren fliegt.

Was ich aber nicht verstehe, warum ist das Adapter Konstrukt derart komplex. Entwicklung auf Github, danach muss er als npm veröffentlicht werden und im repo testing per pull-request eingetragen werden. Nach dem testing neue Version und publishen und wieder pull-request ins repo. Boahh, ich habe bis heute die Änderungen vom Alpha2 nicht in npm erneuert und auch nicht ins repo eingetragen, weil inzwischen alle User das Github nutzen. Ich entwickle als Hobby, muss zum Glück nicht davon leben. Und ein Hobby soll es bleiben. Wenn es mich nervt und belastet, höre ich auf. Ich denke das darf man sich auch herausnehmen, wenn man seine Freizeit dafür nutzt und nichts damit verdient, verdienen will.

Ich supporte meine Adapter weiter, soweit es meine Zeit zulässt. Die meisten nutze ich auch selbst Aber an neuen Adaptern habe ich die Lust verloren, leider.
Grüße Eisbaeeer

[sigi234]

@eisbaeeer sagte in Core-Entwicklung zu schnell?:

Aber an neuen Adaptern habe ich die Lust verloren, leider.
Grüße Eisbaeeer

Und das finde ich wirklich schade aus Usersicht.

[AlCalzone]

@eisbaeeer sagte in Core-Entwicklung zu schnell?:

warum ist das Adapter Konstrukt derart komplex

Finde ich ehrlich gesagt nicht.

• Auf Github liegt der Code, in vielen Fällen auch ausführbar und alles was zum Entwickeln benötigt wird
• Auf npm liegen Versionen, die vom Entwickler als fertig eingestuft werden. Ohne unnötigen Entwickler-Schnickschnack und oft wesentlich schneller und reproduzierbarer zu installieren als von git (wichtig für's UX)
• Im ioBroker Repository ist hinterlegt,
  • ...dass es den Adapter gibt (wichtig für die Adapterliste)
  • ...und welche Version auf npm als stable eingestuft wird (wichtig für User, die ein funktionierendes System wollen).

und im repo testing per pull-request eingetragen werden

Sorry, ich kann dir hier nicht folgen. Was meinst du? Das Update der stable-Version? Das ist ne Sache von ner Minute.

ich habe bis heute die Änderungen vom Alpha2 nicht in npm erneuert

Was hindert dich? https://github.com/AlCalzone/release-script kennst du? Damit ist auch das npm-Release eine Sache von "Befehl absetzen, paar Minuten warten".

[OliverIO]

Ich würde @Eisbaeeer schon zustimmen. Acuh zu einigen Beiträgen weiter oben

@alcalzone sagte in Core-Entwicklung zu schnell?:

warum ist das Adapter Konstrukt derart komplex

ok nicht der derart komplex, aber schon umfangreich und überhaupt nicht durchgängig dokumentiert ala. man muss sich durch diverse Dokumentationsquellen unterschiedlichster Stände und Alters durcharbeiten und ist sich danach immer noch unsicher ob das nun richtig ist. Die Überaschung kommt dann im Adapterchecker (kennen den den alle?) oder im Review.
Bei Fragen die hier mehr ins Detail geht, bekommt man im Forum meist keine Antwort.

@alcalzone sagte in Core-Entwicklung zu schnell?:

Auf Github liegt der Code, in vielen Fällen auch ausführbar und alles was zum Entwickeln benötigt wird

Den können Anfänger aber meist nie überblicken und es fehlt oft an den Grundkenntnissen des debuggings. Ich musste mich selbst auch stundenlang durch den Code bei iobroker und vis steppen (hab ich schon erwähnt, das man zu manchen Fragen keine Antwort hier erhalten hat)

@alcalzone sagte in Core-Entwicklung zu schnell?:

Was hindert dich? https://github.com/AlCalzone/release-script kennst du?

Warum musst du fragen ob er kennt?
ich kannte es jetzt auch nicht.
Wo hätte es man den nachlesen können?
Sag jetzt nicht im github, wenn dann muss man den Weg genau dahin finden.
(hatte ich schon die verschiedenen Dokumentationsquellen erwähnt?)

Du beschäftigst dich sehr umfangreich mit iobroker und auch den Innereien von iobroker. Das schaffen, ich würde mal sagen 95%, der Leute hier nicht.

Dem Punkt von weiter oben, erst die Basisdoku so aufzubereiten, das es für User und Devs anwendbar ist und nicht alles hier im Forum erfragt werden muss.
Die Doku muss erster Anlaufpunkt für alle sein. Von dort aus kann gerne überall hin-verlinkt werden, aber die Suche im Forum oder in Google führt zu oft auf alte/nicht aktuelle Stände, was automatisch im Optimalfall wieder zu Fragen im Forum führt, im schlechtesten Fall zu Frust und oft wird das nicht kommuniziert, sondern die Leute hören einfach auf oder finden sich ab.

Aber das Thema Doku wurde ja schon verschiedentlich aufgegriffen. Eine diskutierbare Roadmap dafür hab ich leider noch nicht gesehen.
Meiner Meinung nach sollte jeder befähigt werden die Doku zu pflegen, ansonsten bleibt das bei wenigen Personen hängen (wie bisher).

[Thomas Braun]

@oliverio sagte in Core-Entwicklung zu schnell?:

Meiner Meinung nach sollte jeder befähigt werden die Doku zu pflegen, ansonsten bleibt das bei wenigen Personen hängen (wie bisher).

Hat zwar nicht mit der Core-Entwicklung direkt zu tun, aber das sage ich schon lange. Ich hätte vielleicht das ein oder andere an der Dokumentation schon verbessert, wenn das nicht so Klimmzüge bedeuten würde. Ich glaube ich hatte auch mal die Doku aus git geforkt und mich daran versucht, aber das war so umständlich und langwierig, da hab ich die Lust wieder dran verloren. Da schreib ich lieber im Forum ein HowTo, auch wenn das dann 'irgendwo ungeordnet' herumfliegt.

[AlCalzone]

@oliverio Also zusammenfassend: es mangelt erheblich an der Doku. Trifft es das?

Ich weiß - auch wieder nur eine zusätzliche Anlaufstelle, aber @UncleSam und ich empfehlen gerne https://github.com/ioBroker/create-adapter bzw. dessen Changelog.
Dort ist zumindest für das erzeugte Grundgerüst erklärt, was sich (teils auch warum) ändert, was es für Neuigkeiten gibt und wie man das selbst für einen bestehenden Adapter auf die Kette bekommt.

Adapter, die mit dem Creator erstellt werden, haben von Haus aus das release-script an Bord.

---

Auf Github liegt der Code, in vielen Fällen auch ausführbar und alles was zum Entwickeln benötigt wird

Den können Anfänger aber meist nie überblicken und es fehlt oft an den Grundkenntnissen des debuggings

Ich glaube du hast missverstanden was ich sagen wollte. Ich habe lediglich erklärt, warum es diese 4 Anlaufstellen (github, npm, latest und stable repo) gibt.

[OliverIO]

@thomas-braun sagte in Core-Entwicklung zu schnell?:

@oliverio sagte in Core-Entwicklung zu schnell?:

Meiner Meinung nach sollte jeder befähigt werden die Doku zu pflegen, ansonsten bleibt das bei wenigen Personen hängen (wie bisher).

Hat zwar nicht mit der Core-Entwicklung direkt zu tun, aber das sage ich schon lange. Ich hätte vielleicht das ein oder andere an der Dokumentation schon verbessert, wenn das nicht so Klimmzüge bedeuten würde. Ich glaube ich auch mal die Doku aus git geforkt und mich daran versucht, aber das war so umständlich und langwierig, da hab ich die Lust wieder dran verloren. Da schreib ich lieber im Forum ein HowTo, auch wenn das dann 'irgendwo ungeordnet' herumfliegt.

Genau so!

[OliverIO]

@alcalzone sagte in Core-Entwicklung zu schnell?:

@oliverio Also zusammenfassend: es mangelt erheblich an der Doku. Trifft es das?

ja genau

[Homoran]

@alcalzone sagte in Core-Entwicklung zu schnell?:

Also zusammenfassend: es mangelt erheblich an der Doku. Trifft es das?

Auch wenn es hier um die Dev-Doku geht, gilt das selbe analog auch für die User-Doku.
Und ich denke dass @Thomas-Braun diese meinte.

Der Kernsatz war

@oliverio sagte in Core-Entwicklung zu schnell?:

Die Doku muss erster Anlaufpunkt für alle sein. Von dort aus kann gerne überall hin-verlinkt werden

und zwar für beide Dokus

[Eisbaeeer]

Adapterchecker ...
Gutes Tool und ich denke auch die richtige Richtung. Travis ist gut. Automatisiert. Aber ich bin auch schon daran verzweifelt. Auch so eine Hürde. Ich bin wahrscheinlich der diletantestete Entwickler und sollte bei C+ bleiben. Ich finde es auf jeden Fall gut, dass man eine Selbstreflektion betreibt und hoffe, dass nur das Gute bleibt.

Toll wäre auch ein Organigram der Core Entwickler und ein Ansprechpartner, wenn es um Adapter geht. Der könnte auch das Sprechrohr zu den Core Entwicklern sein.

[OliverIO]

@eisbaeeer
ich scheitere an der dependabot-integration in github
leider auch eine der unbeantworteten Fragen hier im Forum

[apollon77]

@eisbaeeer sagte in Core-Entwicklung zu schnell?:

Toll wäre auch ein Organigram der Core Entwickler und ein Ansprechpartner, wenn es um Adapter geht. Der könnte auch das Sprechrohr zu den Core Entwicklern sein.

Hm ... Organigram ... ich versuchs mal: Bluefox, Apollon77, AlCalzone, foxriver76 (gleichberechtigt mit nem kleinen Project owner Bonus für Bluefox); Admin- und andere FE Adapter: Bluefox

Ansprechpartner: GitHub Issues oder jeder von uns; ich denke indirekt landet das meiste am Ende bei mir momentan
Ansprechpartenr "Support": Die Entwickler Community Gruppen in Discord, telegram und Forum ... weil die Community Intelligenz ist besser als ne einzelne.

Ich denke auch das es kein "Sprachrohr" braucht ... Lasst uns zusammenarbeiten. Dann kommt das beste raus.

[apollon77]

@oliverio Auch wenn offtopic: Link? Wir haben weit über hundert Adater mit dependabot ... wäre ja gelacht

[apollon77]

Hallo alle miteinander und vielen Dank für Eure Beiträge, Infos und Meinungen bisher.

Ich werde nicht alles kommentieren, sonst säße ich ja morgen früh noch und ist auch an vielen Stellen gar nicht nötig. Zu ein paar Dingen möchte ich aber gern meine Meinung sagen. Wird fürchte ich ein bissl länger und ob der Zeit auch definitiv nicht Schreibfehlerfrei - schon mal Sorry dafür.

Generell habe ich das Gefühl das wir manchmal zu sehr im "meckern" verweilen und gar nicht die Veränderungen bzw. an vielen Stellen Verbesserungen der letzten 2-3 Jahre sehen. Bis vor 3 Jahren war der js-controller und alles in Core weitestgehend eine One-Man-Show. Seit Mitte 2018 mischen auch weitere Entwickler am js-controller mit und hier versuchen wir die Kommunikation und viele Dinge zu verbessern. Das geht aber nicht von heute auf morgen sondern braucht Zeit, da wir das ALLE als Hobby machen (inklusive Bluefox bisher!).

Kommunikation

Seit Controller 1.5 in 2018 werden js-controller Releases geplant und von mir versucht bestmöglich zu organisieren und zu betreuen. Das war meine Form zu versuchen besser und transparenter zu kommunizieren.

Mit der Zeit kam zuerst Telegram als Kommunikationschannel zum Forum hinzu und später Discord. Seit Mitte 2020 gibt es die Developer-Meetings, wo oft frühe Einblicke in kommende Dinge gegeben werden. Eine Verbesserung in der Kommunikation - auch weil es Protokolle gibt. Dort wurden z.B. früh die Deprecations im Controller 3.3 angekündigt und auch dort hat niemand erwartet was dann beim Beta Release passiert ist. Wir haben sogar gemeinsam die Chance verpasst: Viele Entwickler haben nach Info im Meeting (sorry, facts) auch nicht die Chance genutzt Ihre Adapter, wie gebeten, vor dem Alpha Release in die Community mal zu testen. Als ich gefragt habe wer gecheckt hat gabs nur betretenes Schweigen ...

Ich bin ehrlich, dass ich manchmal nicht mehr weiss was ich noch auf welche Art und wie kommunizieren soll das es gelesen und auch beachtet wird oder Feedback kommt. Sagt mir gern (vllt direkt als PN) was ich anders tun kann. Neben Controller habe ich auch in Absprache mit Bluefox bei vielen anderen Adaptern versucht die Kommunikation sinnbringend zu machen im Forum und auch vorab - Admin 5 als Beispiel.
... am Ende bringt die beste Kommunikation nichts die nicht "ankommt" und bei Kommunikation ist es ja DAS was zählt ...

Wir versuchen hier ebenfalls über automatisch generierte Issues alle Adapter-Entwickler zu Neuerungen zu erreichen - zuletzt in größerem Stil bei js-controller 3.3 und Node.js 14/16 passiert. Wir können hier nur Versuchen den Ball zuzuwerfen - aufnehmen muss Ihn schon der Entwickler selbst.

Ansonsten ist es inzwischen aber auch eine Herausforderung alle Kommunikationskanäle im Blick zu haben und ich persönlich versage dabei wenn ich nicht getaggt werde leider oft. In den meisten Fällen gibt es dann aber andere Entwickler die die Infos haben oder ggf. dann jemanden kennen/taggen der helfen kann. Zusammenarbeit ist Key.

Entwickler-Tooling

Es ist Wahnsinn was - vor allem im letzten Jahr - an Community-Initiativen und -Tools entstanden ist. Wir sind auf einem guten Weg und das sollten wir auch bewusst sagen und "feiern"!
Einige der Posts gehen noch auf Adapter zurück die das aktuelle Tooling nicht kennen bzw nutzen und ja - ohne das man sich selbst informiert sieht man das nicht. Wie gesagt - es hat sich einiges getan in den letzten 1-2 Jahren. Ein Release ist mit einem Shell Befehl heutzutage getan was früher mehrere manuelle Schritte waren
Auch der Dev-Server für die Entwicklung ist ein großer Fortschritt!
Für diese (komplett optionalen Dinge) erzeugen wir keine Massen-Issues auf GitHub und ja es kostet initial Zeit um danach Zeit zu sparen.

Dokumentation

Auch dies ist ein Dauerbrenner seit 3+ Jahren und ich bin sehr froh das sich vor ein paar Wochen @UncleSamSwis das Thema genommen hat und jetzt mit einem Team als Community-Initiative treibt. Das ist einfach ein ganzes Haufen Holz was da in eine sinnvolle Form gebracht werden will und bisher hat dies zeitlich niemand hinbekommen. Umso dankbarer bin ich dem neuen Dev-Doku-Team.
Nachdem es steht werden wir sicherlich sinnvolle Prozesse finden das es auch wirklich aktuell bleibt - und hier bitte ich gleich das JEDER aus der Adapter-Dev-Community hier in Zukunft mithelfen sollte. Ohne Feedback und PRs für Fehler, fehlende oder unklare Themen diskutieren wir in 2 Jahren immer noch warum denn die Doku jetzt zentralisiert aber immer noch "blöd" ist (was sehr frustrierend für die Devs wäre die sich dem Thema jetzt initial annehmen).

Core-Entwicklungsprozess

Mir scheint das hier falsche Ansichten bzw. auch Erwartungen vorherrschen. Generell ist der ioBroker Entwicklungsstil eher agil und iterativ geworden - was Adapter angeht und auch was Core-Features angeht. Auch hier gilt: jemand hat eine Idee, diskutiert diese mit ausgewählten Entwicklern, dann wird Sie ggf. justiert und dann verworfen oder kommt auf den Plan in eins der Projekte - und derjenige oder ein anderer der Core-Devs implementiert die dann meistens auch. Das ganze im Normalfall via GitHub Issues. Oder ein erster Schritt wird gebaut, sodass man dann weitersehen kann was als nächstes Sinn macht und was wie gut von den Entwicklern und Usern angenommen wird. Ist damit ein Thema zu 100% "bis ins letzte Detail zu Ende gedacht"? Nein. Ist das das Ziel? Nein. Dennoch versuchen wir unser bestes keine losen Enden zu haben und uns für die Zukunft nichts zu verbauen. Das kostet viel Zeit das so zu durchdenken.

Wir haben bei mehreren Themen versucht mal frühe Diskussionen in größerer Runde zu führen ... Das Ergebnis war meistens das sich diese Diskussionen nie auf "das Ziel" fokussiert haben sondern immer in alle möglichen Sonderfälle und Kleinkram verstrickt haben. Am Ende steht der Entwickler mit einem Wunschkatalog da der das Feature aufbläht und er sich danach rechtfertigen muß wenn er genannte Wünsche nicht umgesetzt.
Auch hier gilt: Wir machen das als Hobby und das sollten wir alle bitte nicht vergessen wenn wir "Forderungen" an die Core-Entwicklung erheben.

Bei allen größeren Themen haben wir in jedem Fall einen Plan ... der ist aber meist sehr langfristig angelegt und das ist auch gut so.

Bei allen Änderungen ist immer mindestens ein zweiter Entwickler da der den PR reviewt und auch hier wird kräftig diskutiert und die Risiken der Änderungen betrachtet. Wir machen beim Controller nichts leichtfertig.

Gleiches gilt aktuell für die Frontend-lastigen Adapter. Wir haben keinen UXer, keinen Grafiker, keinen Designer und sehr wenige Frontend-Entwickler. Die würden sich über Anforderungen freuen ... aber Sie müssen sich sich selbst ausdenken. Also tun Sie das nach bestem Wissen und Gewissen - und ja die persönliche Handschrift ist dann sichtbar. Feedback kann per GitHub kommen und dann entscheidet der Entwickler was er damit macht - wie jeder von Euch bei seinen Adapter auch! Warum sollte das denn hier anders sein?

@jey-cee sagte in Core-Entwicklung zu schnell?:

das andere sind Funktionen die eigentlich ein Zentraler Bestandteil sein sollten, müssen vom Adapter Entwickler selber gebaut werden. Mal so ein Beispiel: Das löschen von Objekten mit samt darunter liegenden Objekten. Gibt es diese Funktion mittlerweile?

Das ist ein schönes Beispiel. Ja gibt es - seit fast 2 Jahren mit js-controller 2.2.8 (2020-01-24), steht im Changelog ... es wurde irgendwie in nem Thread im Forum angesprochen das es fehlt und immer wieder Aufwände macht und Bluefox hat dann ein GitHub-Issue angelegt und in der nächsten Controller Version war es drin. Mal abgesehen vom "Umweg" über Bluefox ist das so gelaufen wie es sollte. Ich bin dagegen das die Core-Devs erraten was so alles gebraucht werden könnte, sondern das die Entwickler einfach Ihre Schmerzpunkte melden und wir schauen dann was wir tun können (oder es kommt gleich ein PR). That's the way to go!

"Nötige" Adapteranpassungen

@jey-cee sagte in Core-Entwicklung zu schnell?:

Es gibt doch gar keine Garantie dafür das man Sauber Arbeitet (siehe Konsistenz & Rückwärts-Kompatibilität). Und Rückblickend betrachtet gibt es keinen Grund an zu nehmen das nicht Plötzlich Themen auf der Agenda stehen, die Anpassungsarbeit erfordern. Klar ein Break in form von Admin 2 auf 3 ist selten, im Idealfall passiert das nie.

Ja und auch ich kann dir diese Garantie nicht geben. Genauso wenig hast Du eine Garantie das Nodejs 18 nicht nen Breaking change enthält der dir alles kaputt macht oder eine deiner Libraries in einer neuen Version alles umstellt. Sorry, that's (Developer) Life ...

Im Gegensatz zu den anderen oben genannten echt Breaking Fällen haben wir im Controller noch nichts relevantes wirklich ge-breaked und irgendwie kommt es mir immer unwahrscheinlicher vor das wir das jemals tun können ohne gewisse Adapter zu verlieren oder es selbst anpassen zu müssen. Wenn wir es gebreaked hätten, dann gäb es jetzt immer noch keinen js-controller 3.
Ein anderes Beispiel ist Admin 5 der jetzt übrigens neben JSONConfig (ausser für den Custom teil) immer noch die Konfig-UIs von Admin <=2, 3 und 4/5 unterstützt. Glaubt jemand das das jemals raus kann?
Aber kann denn das unser gemeinsames Ziel sein das wir solchen Technical Dept sammeln?

Fazit

Am Ende sehe ich das wir alle das gleiche wollen: Ein gut dokumentiertes System was Spass macht und es "einfach" macht nen coolen Adapter zu entwickeln. Wenn jetzt jeder ein bissl über den Tellerrand schaut und auch schaut was andere tun müssen dafür und wo man am gleichen Strang ziehen sollte und sich gegenseitig helfen sollte/muss dann erreichen wir das gemeinsam auch. Aber es ist ein Weg - wir haben Ihn vor 2,5 Jahren begonnen und sind noch lange nicht am Ende ... ja es wird auf dem Weg noch ein paar Stolperstellen geben und auch mal wehtun. Zusammenarbeit hat uns schon dahin gebracht wo wir jetzt sind ... und bestimmt noch viel weiter

Gute Nacht (bzw. guten morgen, je nachdem wann Ihr es lest)

Ingo

[apollon77]

@mickym mqtt ist seit Admin 5.2.1 mit erlaubt --> https://github.com/ioBroker/ioBroker.admin#521-2021-11-28