FHEM Forum

Edit - 12.02.2015 - inzwischen kam hier im Thread die Frage nach der künftig bevorzugten Versionsverwaltung auf.

Bitte runterscrollen oder klicken http://forum.fhem.de/index.php/topic,20395.msg260898.html#msg260898 :)

---

Mit meiner Client Software (Versions 1.3.0) bekomme ich heute regelmäßig Error 500 beim Commit ins SVN.
Von der OS-Konsole per svn commit funktioniert alles wie üblich.

Gab es irgendwelche Änderungen?

Macht auch über das Web Probleme. Slow und 500 internal server...

vg
Jörg

Ich habe nichts geaendert. Sourceforge at its best. Seufz.

zumindest bin ich beruhigt, dass ich nicht alleine mit dem Problem bin :)

gibts heute wieder irgendwelche Probleme mit SVN?

Ja:

ZitatTransmitting file data .svn: E000030: Commit failed (details follow):
svn: E000030: Can't open file '/svn/p/fhem/code/db/txn-current-lock': Read-only file system

same problem
svn commit -m "00_THZ.pm: improvement in communication for slow interfaces"
Sending        fhem/FHEM/00_THZ.pm
Transmitting file data .svn: E000030: Commit failed (details follow):
svn: E000030: Can't open file '/svn/p/fhem/code/db/txn-current-lock': Read-only file system


ok, danke. Dann muss ich mir keine Gedanken machen :)


ERROR from SVN:
RA layer request failed: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/p/fhem/code/!svn/me'
W: 9c8dafaaf3ec329cf12327b0ee9448521340cf89 and refs/remotes/trunk differ, using rebase:
:040000 040000 5ea392262c43664858633261af61d1c82cee22ce fcaddd2f6f9379353efd2791357df050851fa1e4 M fhem
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.


irgendwie klemmts heute wieder...


ERROR from SVN:
RA layer request failed: Server sent unexpected return value (500 Internal Server Error) in response to POST request for ...


ich konnte vorgestern auch nichts einchecken...

(git haben wollen ;) )

Zitat von: hexenmeister am 12 Februar 2015, 20:59:54
(git haben wollen)

*unterschreib*

Mach doch mal eine Umfrage, aber vergiss das Toastbrot nicht.

Bitt'schön!  ;D
*duck*

ich würde mich sowieso freuen, wenn FHEM von Sourceforge weggeht, da wir bis auf das SVN keine weiteren Features von Sourceforge nutzen (Tickets, Release-Downloads, usw.). Toll wär ein SVN Server direkt unter fhem.de , da weis ich aber nicht, ob das ressourcentechnisch möglich ist.

git habe ich bisher nicht genutzt, bin ich aber nicht gegen abgeneigt.

PS: dass das Toastbrot alle ist, finde ich sehr schade, dabei mag ich doch so gerne Toastbrot ;-)

Zitat von: Markus Bloch am 13 Februar 2015, 16:55:13
Toll wär ein SVN Server direkt unter fhem.de , da weis ich aber nicht, ob das ressourcentechnisch möglich ist.

Wenn schon was Neues/Eigenes aufsetzen, dann aber doch bitte nicht mehr SVN.
An den Ressourcen soll es nicht scheitern, da kann ich helfen.

juhu, SF ist wieder mal down.....

@Rudi: was meinst du denn so generell zu dem Thema?

Das waere der zweite Umzug (zuletzt vom berlios nach sourceforge), und ich habe behalten, dass es ein Haufen Arbeit ist (jedenfalls was mich betrifft), mit wenig Netto-Gewinn.

- man muss einen besseren Server als Sourceforge besorgen. Wobei besser subjektiv ist: ich wuerde einen Standort in Deutschland bevorzugen, und ein Rechenzentrum, damit man nicht auf die Anwesenheit von einem Privatperson beim Hardwareproblemen angewiesen ist.
- auf dem Rechner muss eine Benutzerverwaltung fuer diesen Zweck installiert sein, also Userpflege+GIT aber kein echter Zugang.
- die Entwickler muessen sich alle neu anmelden, d.h. man muss 40-50 Leute neu berechtigen.
- Quellen ruebertragen (ich will die alten Versionen nicht verlieren)
- fhemupdate + meine lokale Sicherung der Quellen anpassen
- mich in Git + Git-Hooks einarbeiten, Hooks erstellen.
- fhem-doku anpassen.
- FHEM@sourceforge zumachen.
- alle Entwickler muessen die Quellen neu auschecken, und darauf achten, dass lokale Aenderungen nicht verloren gehen.
- Uebrigbleiben etliche tote Links im fhemwiki/Blogs/etc.

Auf der Haben Seite sollte eine stabilere Verbindung stehen, d.h. man kann dann einchecken, wenn man will.

-> Im Moment wuerde ich das Problem eher aussitzen, es sei denn sourceforge kriegt es nicht hin.

Zumindest die ersten vier Punkte Deiner Liste habe ich bereits länger umgesetzt :) Bei mir läuft ein git repository, in dem ich auch alle Benutzer, die hier in "SVN Schreibberechtigung" aufgelistet werden, auch als git-User mit Certificate-Authentication vorhanden sind.

wenn man wechselt, kann man dann nicht einen smoothen Übergang machen?

Neues System spiegelt erst einmal die SourceForge Version sodass es mit beiden funktioniert? Und danach SF auf ReadOnly umstellen und irgendwann abschalten?

Was ist den an Traffic von uns auf dem SF Server?

Zitat von: rudolfkoenig am 20 Februar 2015, 20:15:39
- die Entwickler muessen sich alle neu anmelden, d.h. man muss 40-50 Leute neu berechtigen.

Die Entwickler müssen sich nicht neu anmelden, sie bekommen lediglich neue Zugangsdaten, das lässt sich weitgehend automatisieren (verbunden mit einem gleichzeitigen Check, ob die registrierten email-Adressen noch aktuell sind)

Ein eben ausgeführter Migrationstest hat ergeben, dass  das nicht 40-50 Personen wären, sondern 109 - nämlich alle User, die bisher jemals in svn eingecheckt haben. Die müssen auch dem migrierten git bekanntgemacht werden.

Zitat von: Wuppi68 am 21 Februar 2015, 11:11:09
wenn man wechselt, kann man dann nicht einen smoothen Übergang machen?

Eine Migration von svn zu git läuft normalerweise so ab, dass in der Migrationsphase alle Entwickler weiterhin nach svn einchecken und das svn dann nach git als read-only gespiegelt wird. Irgendwann kommt dann der Zeitpunkt des Umschaltens. Ab diesem Moment wird svn gesperrt und git freigegeben, danach wird nur noch in git eingecheckt.

Zitat von: rudolfkoenig am 20 Februar 2015, 20:15:39
Das waere der zweite Umzug (zuletzt vom berlios nach sourceforge), und ich habe behalten, dass es ein Haufen Arbeit ist (jedenfalls was mich betrifft),

Nirgends steht geschrieben, dass Du einen solchen Umzug alleine stemmen musst. Falls Du eine Migration irgendwann doch ins Auge fassen solltest, melde Dich einfach. Die meisten der von Dir oben beschriebenen Aufgaben sind bereits erledigt und müssen nur noch scharfgeschaltet werden.

Heute ist meine Testmigration auf einen eigenen Server im Rechenzentrum umgezogen. Wer gerne mal git "fühlen" möchte, kann unter der Adresse git://fhem.betateilchen.de/fhem_ro.git auf das fhem-Repository per git zugreifen.

Achtung: Der Zugriff ist read-only!

Es sollten alle fhem releases seit 4.0 zu finden sein - mehr ist offenbar auch in svn nicht vorhanden. Die Synchronisation zu fhem-SVN sollte mit einer maximalen Verzögerung von fünf Minuten stattfinden.

Hallo Rudi,

Zitat von: rudolfkoenig am 20 Februar 2015, 20:15:39
- mich in Git + Git-Hooks einarbeiten, Hooks erstellen.

Der pre-receive hook für git, der die commit-Message und die commandref prüft, funktioniert inzwischen auch 8)

Allerdings habe ich dazu noch eine Frage:



      if($l =~ m/^=begin html$suffix$/) {
        $l = <MOD>;    # skip one line, to be able to repeat join+split
        err($fName, "$lang: nonempty line after =begin html.")
          if($l =~ m/^...*$/);
        $skip = 0; $line++;



Das bekomme ich im hook noch nicht abgebildet, weil ich nicht direkt aus der Datei lesen kann, sondern aus dem im commit geschickten content. Also arbeite ich mit foreach() ein Array ab und innerhalb dieser Schleife kann ich natürlich nicht einfach eine weitere Zeile lesen.

Wieso ist das Fehlen der Leerzeile nach =begin_html ein Fehler?


Hast Du noch weitere hooks in SVN im Einsatz? In ./contrib habe ich nichts gefunden - oder ich habs übersehen.

Die Leerzeile ist aus historischen Gruenden da: Doku in den Modulen ist erst 3 Jahre alt, davor musste jeder commandref.html modifizieren. Als es absehbar war, dass es so nicht weitergeht, habe ich commandref_split & join gebaut. Da ich unsicher war, ob split/join richtig funktioniert, wollte ich sicherstellen, dass nach split+join die Doku mit dem alten identisch ist. Ich meine mich daran zu erinnern, dass split immer ein Leerzeichen einfuegt, und falls im Input das nicht vorhanden ist, dann meldet ein anschliessend gemachter diff Unterschiede.
Vermutlich kann man die Pruefung entfernen.

Ich habe z.Zt. nur diesen Hook im Einsatz.

Danke für die Info.

Für alle Statistik-Freaks:

https://fhem.betateilchen.de/statistics.html

https://fhem.betateilchen.de/gitstat

(Aktueller Stand, täglich aktualisiert, Auswertungszeitraum ab 01.01.2015)

Ich weiss nicht, ob ich das auch als Statistik bezeichnen wuerde:

ZitatNot Found
The requested URL /statistics.html was not found on this server.
Apache/2.2.22 (Debian) Server at fhem.betateilchen.de Port 443

Wir sind ja schließlich nicht auf einer Berliner Flughafenbaustelle  8) Auf meiner Baustelle hier wird jedenfalls auch am Freitagabend fleißig gearbeitet, damit was fertig wird. So ungefähr sollte das Ergebnis aussehen:

(http://up.picr.de/21129472by.jpg)

Jetzt musst du nur noch erklaeren, wie du die Statistiken berechnet hast.
Ich kaufe es dir naemlich nicht ab, dass Du doppelt so viel an FHEM geaendert hast, wie ich. :)

http://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics (http://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics) :
'There are three kinds of lies: lies, damned lies, and statistics.'

Das steht doch in den Spaltenüberschriften? commits, insertions und deletions.

Zitat von: rudolfkoenig am 27 Februar 2015, 23:26:15
Ich kaufe es dir naemlich nicht ab, dass Du doppelt so viel an FHEM geaendert hast, wie ich. :)

Wie ich weiter oben bereits geschrieben hatte, ist der Betrachtungszeitraum der Statistik das laufende Jahr 2015. Und in den vergangenen zwei Monaten habe ich definitiv mehr eingecheckt als Du, denn Jan/Feb war die Geburt von 55_InfoPanel und 98_help - da sind die 3471 Zeilen code durchaus realistisch, das InfoPanel alleine hat aktuell knapp 2000 Zeilen.

Ich war auch erst verdutzt, aber wenn man vom 01. Januar ausgeht, dann kommt das bei mir schon hin. Hab nur wenige Sachen seit dem eingecheckt.

Der Betrachtungszeitraum und das Erstellungsdatum der Liste stehen jetzt auch ganz oben auf der Seite.

Aus Performancegründen - um die Statistik überhaupt zu testen - habe ich den Zeitraum einfach aktuell noch begrenzt. Natürlich kann man die Auswertung auch über die gesamte fhem-Zeitrechnung laufen lassen.

Ich bräuchte mal bitte 3-5 Anwender, die mich als Testuser bei der Einrichtung eines git-Servers unterstützen. Vor allem, um evtl. auf Anwenderseite auftretende Schwierigkeiten in einer entsprechenden Doku berücksichtigen zu können.

Wer Interesse hat, meldet sich bitte per email (http://forum.fhem.de/index.php?action=emailuser;sa=email;msg=267913) bei mir.

sind GIT-Kenntnisse mandatory?

nö, letztendlich ist das auch nicht schwieriger als svn.

Ich bringe recht gute Git Erfahrungen mit und könnte testen.

ja und? Mach doch.

Ich weiß ja leider nicht, was du getestet haben möchtest. Mit einem einfachen Checkout dürfte dir wohl nicht geholfen sein?
Zumal http://fhem.betateilchen.de nicht erreichbar scheint.

Da Du offenbar des Lesens (oder des Verstehens) von einfachsten Forumbeiträgen hier im Thread nicht mächtig bist, scheidest Du als Tester ohenhin aus. Sorry.

Sei doch nicht immer so biestig, nur weil man dich darauf hinweist, dass dein Webserver temporäre Probleme beim Zugriff über SSL hatte... aber zugegeben, es hat mich amüsiert.


Ich habe die Nachrichten hier sehr wohl aufmerksam gelesen. Inzwischen hast du jedoch alle relevanten Infos durchgestrichen, sie sollen wohl obsolete sein.
Aber auch davor war meine Frage gerechtfertigt: Was hast du davon, wenn jemand einfach nur was auscheckt? Das kannst du auch selbst testen, oder nicht? Oder ging es dir darum, dass ich mich in einer geheimnisvollen E-Mail an dich wende, statt öffentlich auf den Beitrag zu antworten?

culfw wird seit heute auch regelmäßig als eigenes git repository auf git.fhem.de migriert. Die Aktualisierung erfolgt allerdings nur einmal pro Tag, da sich dort nicht so häufig Änderungen ergeben.

Wie ist denn eigentlich hier nu die offizielle Marschrichtung?

Bleiben wir bei Sourceforge, oder wird FHEM (und evtl. auch culfw) wo andershin umziehen und dabei evtl. auch auf git schwenken?

Wäre ganz interessant zu wissen.

Gruß
Markus

Kommt Zeit, kommt Rat git ...

Nur nicht drängeln, ich vermute, Rudi wird sich dem recht eindeutigen Votum seiner Umfrage nicht auf Dauer verweigern.

*rauskram*

Wieso gibt es git.fhem.de eigentlich nicht mehr?

ZitatNur nicht drängeln, ich vermute, Rudi wird sich dem recht eindeutigen Votum seiner Umfrage nicht auf Dauer verweigern.

Da hat er sich nun aber über drei Jahre erfolgreich widersetzt.

Inzwischen habe ich Erfahrung mit git sammeln duerfen, und ich bin dankbar, dass ich es in wenigstens in FHEM nicht verwenden muss: mAn bietet git Features, die bei FHEM nicht benoetigt werden, und ist selten unlogisch in der Benutzung.

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

Lokale Anpassungen mit SVN nachzuziehen ist um Einiges arbeitsaufwändiger (und fehlerträchtiger) als mit git. Meine Erfahrung ...

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

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 (https://blog.seibert-media.net/blog/2014/04/25/git-workflows-der-forking-workflow-teil-2/) 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.

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*

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.

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  >:(

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

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.

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)

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.

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 (https://github.com/mhop/fhem-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.

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 (https://github.com/fhem/fhem-mirror/tree/master) 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 (https://github.com/fhem/fhem-mirror/blob/travis/README.md) im travis Branch.