Autor Thema: [Umfrage] künftige Versionsverwaltung für fhem  (Gelesen 10244 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #45 am: 30 September 2018, 17:33:03 »
Das mag sein, aber lokale Anpassungen zu foerdern ist zZt. nicht meine Prioritaet.

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 441
    • Private Website
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #46 am: 30 September 2018, 20:32:00 »
Das mag sein, aber lokale Anpassungen zu foerdern ist zZt. nicht meine Prioritaet.

Das ist schade, wirklich. Das koppelt FHEM nämlich von den Ideen der Leute ab, die keinen Bock auf den Driss mit Schreibrechten im Subversion-Repository / Maintainer-Bettelei haben.

Ich sehe die Vorteile von Git darin, dass es ein offeneres Modell als ein zentrales SVN-Repository ist, das vom Rest der Welt quasi abgeschottet ist. Setzt man Git in einem forking workflow ein, ist die Hürde von außerhalb Code beizutragen deutlich niedriger.

Ich möchte das mal mit den zentralisierten Workflow, der hier genutzt wird (gleichberechtigter Zugriff auf ein gemeinsames Repository), an einem Beispiel vergleichen:

Ich habe vor einer Weile ein paar Bugs in CUPS gefixt. Ich bin kein Entwickler in dem Projekt, habe also keinen schreibenden Zugriff auf das CUPS-Repository auf Github. Ich habe einfach einen Fork gemacht, die Bugs gefixt und den Projektentwicklern einen pull request, d.h. die Aufforderung/Bitte meinen Code aufzunehmen, geschickt. Das haben sie auch getan, nach dem sie den Code für gut befunden haben (vermute ich). Änderungen die ich gerne an FHEM machen möchte (und zwar nicht nur lokal), kann ich auf einem Klon des Repositories machen, aber dazu muss ich  dann erst einen Schreibzugriff beantragen, aber dann darf ich vielleicht auf ein Modul gar nicht schreibend zugreifen. Dumm wenn man einen Bug fixen will, der irgendwo ist, wo man keine Schreibrechte hat. Also muss ich einen Patch machen / die Änderung beschreiben und den Maintainer kontaktieren, der dann hoffentlich reagiert und den Patch hochschiebt. Das alles ist viel mehr Aufwand als einfach einen pull request per Mausklick nach einer Sichtung zu akzeptieren, wie es bei Git wäre - Aufwand für beide Seiten, der nicht in das Schreiben von Code fließt, sondern in dumme Bürokratie.

Wenn ich außerdem gerade mal ins SVN gucke finde ich da archäologisch sicher spannende branches von 2007/2008, die aber nie hätten dort landen sollen. Sowas kann man auch geschickt umgehen in dem man den Leuten ihr eigenes FHEM-Git-Repository lässt aus dem man dann über pull requests die interessanten Teile übernimmt.
Gefällt mir Gefällt mir x 4 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #47 am: 30 September 2018, 20:40:51 »
Zu diesem Thema ist es völlig unnötig, mit Rudi zu diskutieren, dazu ist er zu sehr in der Vergangenheit verwurzelt und zeigt erfahrungsgemäß wenig Bereitschaft, sich mit irgendwelchen neuen Technologien und deren Vorteilen unvoreingenommen zu befassen.

Alleine diese Aussage

mAn bietet git Features, die bei FHEM nicht benoetigt werden, und ist selten unlogisch in der Benutzung.

belegt diese grundsätzliche Ablehnung eindrucksvoll.

verstehe die dahinter liegenden Konzepte, und es ist logischer als alles Andere was man so findet.

*unterschreib*
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline smurfix

  • Developer
  • Full Member
  • ****
  • Beiträge: 272
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #48 am: 30 September 2018, 21:04:53 »
Das mag sein, aber lokale Anpassungen zu foerdern ist zZt. nicht meine Prioritaet.
Na gut, dann streiche "Lokale Anpassung" und ersetze "Bugfix" und "Erweiterung". Die förderst du damit nämlich auch nicht, zumal Erstere irgendwie die Voraussetzung für Letztere darstellen.

Ich habe keine Ahnung, ob diese Einstellung mehr als einen möglichen Mitarbeiter (mich …) dazu gebracht hat, stattdessen Home Assistant zu verwenden … aber ich nehme es an.

Ich spiele jedenfalls lieber in Sandkästen, in denen ich das Gefühl habe, willkommen zu sein.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17210
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #49 am: 30 September 2018, 21:13:26 »
Na gut, dann streiche "Lokale Anpassung" und ersetze "Bugfix" und "Erweiterung". Die förderst du damit nämlich auch nicht, zumal Erstere irgendwie die Voraussetzung für Letztere darstellen.

Ich habe keine Ahnung, ob diese Einstellung mehr als einen möglichen Mitarbeiter (mich …) dazu gebracht hat, stattdessen Home Assistant zu verwenden … aber ich nehme es an.

Ich spiele jedenfalls lieber in Sandkästen, in denen ich das Gefühl habe, willkommen zu sein.

Sehe ich anders. Du und auch jeder andere Entwickler sind herzlich willkommen. Doch deswegen muss man noch lange nicht nach Deiner Pfeife oder Deinem Wohlwollen handeln. Man kann diskutieren aber sollte nicht versuchen zu erzwingen, oder wie Du gar zu erpressen  >:(
« Letzte Änderung: 30 September 2018, 21:21:47 von CoolTux »
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15286
  • s/fhem\.cfg/configDB/g
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #50 am: 30 September 2018, 21:18:31 »
Nachtrag

mAn bietet git Features, die bei FHEM nicht benoetigt werden

das ist in svn aber nicht anders, da gibt es mindestens genau so viele Features, die in FHEM nicht benötigt genutzt werden...
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline smurfix

  • Developer
  • Full Member
  • ****
  • Beiträge: 272
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #51 am: 30 September 2018, 21:34:01 »
Ich habe nicht vor, irgendwen zu "erpressen". Ich schreibe nur, wie ich mich hier fühle bzw. gefühlt habe, und was ich daraus für Konsequenzen gezogen habe. (SVN ist nicht der einzige Grund; die

Wenn du daraus eine Erpressung ableitest, dass ich *sage* dass ich heutzutage keinen Bock auf den Terz mit SVN und Patches mehr habe, der sich mit git viel einfacher managen lässt, dann ist das ehrlich gesagt nicht mein Problem.

Wie ich Rudi bereits vor zweieinhalb jahren antwortete: Manchmal passen Arbeitsstile nicht wirklich zusammen. Die Gründe anzuführen, wieso das so ist (SVN vs. git, und die unterschiedlichen Arbeitsstile die diese Tools ermöglichen, ist ein großer Teil davon, aber nicht der einzige Knackpunkt – der Rest passt nicht in dieses Thema), wird ja wohl erlaubt sein.

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 441
    • Private Website
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #52 am: 30 September 2018, 21:41:44 »
Sehe ich anders. Du und auch jeder andere Entwickler sind herzlich willkommen. Doch deswegen muss man noch lange nicht nach Deiner Pfeife oder Deinem Wohlwollen handeln. Man kann diskutieren aber sollte nicht versuchen zu erzwingen, oder wie Du gar zu erpressen  >:(

Inwiefern droht dir smurfix irgendein Übel an und was sollte das für eins sein? Er schreibt ja, dass er für sich den Schluss gezogen hat, dass ihm das aktuelle Modell nicht funktioniert und dass er davon ausgeht, dass es anderen Leute ähnlich geht - und er deswegen die Konkurrenz bevorzugt (so habe ich es zumindest verstanden).

Für mich ist das aktuelle Modell einfach nutzlos ineffizient, deswegen halte ich mich mit Code zurück, den ich beisteuern könnte. Dann sind halt irgendwelche Sachen in meiner angepassten FHEM-Installation anders, gefühlt besser, aber ich kann das nicht mal wirklich effizient den Leuten zu kommen lassen, die auch interessiert wären (wie wir gestern bei dem Treffen der FHEM-UG Gütersloh/OWL mehrfach festgestellt haben). Selbst wenn ich meine Patches auf die offizielle Codebasis anwende, sind sie doch mit dem nächsten Update wieder weg, außer ich schließe jede andere Weiterentwicklung aus; mergen ist ja so nicht, weil ich keine lokale, getrennte Kopie des Repositories betreiben kann.

Bisher habe ich übrigens außer "Wir machen schon immer Subversion" noch kein Pro-Argument für Subversion gelesen, just saying.

(Typo korrigiert)
« Letzte Änderung: 30 September 2018, 21:47:00 von Christoph Morrison »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19536
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #53 am: 30 September 2018, 23:04:23 »
Ich sehe zwei unterschiedliche Szenarien:

1. Weitergabe der Aenderungen an dem Maintainer.
Pull requests verleiten dazu, das Problem auf privaten Kanaelen zu diskutieren. Man kann genausogut einen Patch hier im Forum posten, damit der Maintainer es integrieren kann. Dann ist es oeffentlich dokumentiert, zusammen mit den Pro- und Kontra-Argumenten, und Benutzer koennen es vor dem Integrieren testen.

2. Weitergabe der Aenderungen an "Kollegen".
Lokale Aenderungen kann man mit svn auch behalten, nur die Weitergabe einzelner Aenderungen wird kompliziert, wenn man mehrere solche Aenderungen hat. Und damit habe ich kein Problem, ich will beim Support nicht herausfinden muessen, wessen Patches noch dazugekommen sind. Wenn der Maintainer deine Aenderungen nicht will, steht es dir frei, das modifizierte Modul unter deinem Namen anzubieten.


Zitat
Bisher habe ich übrigens außer "Wir machen schon immer Subversion" noch kein Pro-Argument für Subversion gelesen, just saying.
Aenderungen des Versionsystems sind nicht ohne Aufwand, spreche aus Erfahrung, FHEM hat mit CVS angefangen.
« Letzte Änderung: 30 September 2018, 23:06:58 von rudolfkoenig »

Offline Christoph Morrison

  • Developer
  • Full Member
  • ****
  • Beiträge: 441
    • Private Website
Antw:[Umfrage] künftige Versionsverwaltung für fhem
« Antwort #54 am: 01 Oktober 2018, 00:13:45 »
Zitat
Pull requests verleiten dazu, das Problem auf privaten Kanaelen zu diskutieren. Man kann genausogut einen Patch hier im Forum posten, damit der Maintainer es integrieren kann. Dann ist es oeffentlich dokumentiert, zusammen mit den Pro- und Kontra-Argumenten, und Benutzer koennen es vor dem Integrieren testen.

Jeder pull request (PR) kann annotiert und öffentlich diskutiert werden, siehe z.B. (völlig willkürlich): https://github.com/apple/cups/pull/5261
Am Ende steht dann eine Entscheidung ob der PR akzeptiert wird oder nicht, die dann bei einem oder mehreren Maintainern liegt. Das ist doch deutlich öffentlicher als jetzt, wo die Kommunikation vielleicht gar nicht oder privat oder sonst wo stattfindet, mal von den ganzen Features wie milestones / releases / öffentliches bugtracking etc. abgesehen, die wir jetzt nicht haben oder nicht nutzen.

Zitat
Lokale Aenderungen kann man mit svn auch behalten,

Und kann nicht mehr problemlos updaten sobald der svn-automerge nicht mehr richtig funktioniert (was früher oder später immer passiert, btdt), vom FHEM update mal ganz zu schweigen (ja ich kenne die Möglichkeiten des exclude).

Zitat
nur die Weitergabe einzelner Aenderungen wird kompliziert, wenn man mehrere solche Aenderungen hat. Und damit habe ich kein Problem, ich will beim Support nicht herausfinden muessen, wessen Patches noch dazugekommen sind.

Inwiefern müsstest du z.B. für CM's FHEM clone Support leisten? Im Idealfall holt sich ein hypothetischer User einen "Patch" als PR in sein eigenes FHEM, das ein Fork vom offiziellen FHEM ist. Die Antwort auf Leute mit eigenem FHEM-Klon ist dann: Kein Support für deinen crooked clone.

Zitat
Wenn der Maintainer deine Aenderungen nicht will, steht es dir frei, das modifizierte Modul unter deinem Namen anzubieten.

Ja und das funktioniert sogar ohne den Update-Mechanismus von FHEM zu brechen wenn der Maintainer so schlau war sein Modul nicht in das Subversion-Repo zu geben, sondern bei Github oder so geblieben ist. Wenn ich aber was am Kern ändern möchte, du/der Maintainer das nicht akzeptierst, andere das aber sehr wohl wollen, hört der Spaß bei etwas komplexeren Änderungen (siehe oben) schnell auf.

Zitat
Aenderungen des Versionsystems sind nicht ohne Aufwand, spreche aus Erfahrung, FHEM hat mit CVS angefangen.

Ich hab in meiner beruflichen Laufbahn als Softwareentwickler, DevOps und Projektmanager sicher mehrere dutzend Projekte (mit-)migriert, oftmals genau in diesem Setting (svn → git). Vorteil: Es gibt bereits einen Git-Mirror von FHEM, der ist halt nicht offiziell, spiegelt den Schrott der in /branches liegt mit (und der ist einen Tag hinten dran). Aber es geht offensichtlich und da ein Großteil der Projekte und u.a. auch der Linux-Kernel, der ja nun nicht gerade klein oder unbedeutend ist, auf Git setzen, gibt es sicher auch Möglichkeiten die build queue dahinter entsprechend umzugestalten. Ich bringe mich da auch gerne mit ein.
Gefällt mir Gefällt mir x 4 Liste anzeigen