[Umfrage] künftige Versionsverwaltung für fhem

Begonnen von betateilchen, 17 Februar 2014, 20:55:42

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Das mag sein, aber lokale Anpassungen zu foerdern ist zZt. nicht meine Prioritaet.

Christoph Morrison

Zitat von: rudolfkoenig am 30 September 2018, 17:33:03
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.

betateilchen

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

Zitat von: rudolfkoenig am 30 September 2018, 16:54:31
mAn bietet git Features, die bei FHEM nicht benoetigt werden, und ist selten unlogisch in der Benutzung.

belegt diese grundsätzliche Ablehnung eindrucksvoll.

Zitat von: smurfix am 30 September 2018, 17:30:36
verstehe die dahinter liegenden Konzepte, und es ist logischer als alles Andere was man so findet.

*unterschreib*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

smurfix

Zitat von: rudolfkoenig am 30 September 2018, 17:33:03
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.

CoolTux

#49
Zitat von: smurfix am 30 September 2018, 21:04:53
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  >:(
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.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

Nachtrag

Zitat von: rudolfkoenig am 30 September 2018, 16:54:31
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...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

smurfix

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.

Christoph Morrison

#52
Zitat von: CoolTux am 30 September 2018, 21:13:26
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)

rudolfkoenig

#53
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.


ZitatBisher 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.

Christoph Morrison

ZitatPull 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.

ZitatLokale 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).

Zitatnur 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.

ZitatWenn 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.

ZitatAenderungen 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.

Loredo

#55
Ich möchte die Diskussion nicht wieder hervorholen, aber da hier auf den Git Mirror hingewiesen wurde scheint es mir passend zu erwähnen, dass der Mirror ab sofort auch unter github.com/fhem/fhem-mirror bereitsteht und täglich über Travis-CI aktualisiert wird. In der Beschreibung wird darauf verwiesen, dass Pull Requests für den master Branch nicht akzeptiert werden, zusätzlich gibt es einen Hinweis in der README.md im travis Branch.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER