fhem auf github?

Begonnen von robin13, 19 Mai 2015, 14:01:22

Vorheriges Thema - Nächstes Thema

chris_z

Der Thread beweist ganz gut was Github für Vorteile hätte. Bei echter OSS Entwicklung kämen nicht solche Aussagen wie "Ich finde es ganz gut Hürden für Änderungen etwas hoch zu legen".
Auf Github kann halt jeder das Projekt forken und weiterentwickeln ohne fragen zu müssen und um Rechte oder diff Einarbeitungen betteln zu müssen. Ich hab für meinen Teil auf die Weise schon zu vielen Projekten beigetragen was ich sonst nie getan hätte. Da die Pull Requests nicht eingearbeitet werden müssen ist es auch kaum Mehraufwand für die Hauptentwickler, wenn ein pull Request nicht gefällt wird er halt abgelehnt, und gut ist. Es ist auch nicht zu erwarten das da plötzlich tausende Newbies Pull Requests einreichen.
Erhoffen würd ich mir das man Module dann nicht mehr aus dem Forum zusammen copy&pasten muss und mühsam zusammensuchen sondern die schon im repo zu finden sind.
Das Forum ist aus meiner Sicht für fhem durchaus nicht unbedingt "Der Vorteil" sondern eher eine Hürde. Was ich an Zeit zugebracht hab am Anfang um Sinvolle Module erstmal zusammenkratzen zu müssen...

Prof. Dr. Peter Henning

Der Thread beweist ganz gut, was Github für Nachteile hätte.

Wenn jeder das Projekt forken könnte, ohne Support für seine Ergänzungen leisten zu müssen, wäre FHEM tot.

LG

pah

rudolfkoenig

#17
FHEM kann jeder forken, ist GPL. Man kann es auf Sourceforge forken, oder auf github, oder auf dem Forum oder wo auch immer, das ist mehr oder weniger erfolgreich mit culfw passiert. Selbst innerhalb von FHEM sind im begrenzten Umfang forks moeglich, indem man ein Modul kopiert. Der Benutzer kann entscheiden, welchen der Module er einsetzt. Wie das bei etlichen FHEM-Modulen zu sehen ist: entscheidend fuer den Erfolg ist nicht die geniale Umsetzung, sondern der anhaltende Support.

Bei der aktuellen "fork" bestehe ich auf ein paar Prinzipien: jedes Modul hat genau einen Verantwortlichen, der den Ueberblick hat und modulbezogene Probleme werden im Forum behandelt. Das hat sich nach einigen Irrwegen und 10-jaehriger Erfahrung bewaehrt.

Bisher konnte mir keiner die Vorteile von github gegenueber sourceforge klarmachen. Das heisst nicht, dass wir bei sourceforge oder gar SVN bleiben, aber ein Umstieg von sourceforge auf github ist mAn sinnlos.

Wernieman

Vor allem:
Was nutzt einem ein Forke, wenn die Doku fehlt?

Gerade bei "neuen", bzw. in Arbeit befindlichen Modulen ist das Forum für die Erstinstallation Notwendig. Ein reiner GIT-Kommit .... hilft da nicht viel.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

chris_z

Git grundsätzöich hat den Vorteil das man nicht wie bei SVN einen zentralen Server hat sondern jedes Repositore in sich die komplette History enthält und auch quasi als Server eingesetzt werden kann.

Beispiel:
rudolfkoenig baut eine tolle Software namens fhem. Stellt sein repositore öffentlich zur verfügung.
Nun kommt jemand namens jemand daher und meint "kannickbesser".
Macht einen Fork von rudolfs repo, entwickelt 2 Jahre lang massiv weiter die Software macht riesen Sprünge.
Nun kann jeder von "jemand" forken bzw einfach auschecken.

Jemand hat plötzlich Arbeit gefunden oder Freunde oder beides. Rudolph erkennt seine Chance und arbeitet wieder mehr am Projekt.

Das alles funktioniert mit Git und Github ohne Rückfragen, ohne das die beiden sich riechen können müssen, ohne jemanden der den Hut aufhat, und anderen Rechten geben muss.

Alle können offline an "ihren" repos arbeiten und später mergen. Geht auch mal Tage/Monatelang ohne Internet o.ä. Über branches kann man teils imense Änderungen abgeschirmt von allen anderen entwickeln und erst wenn sie Stabil sind in den Hauptzweig mergen.

Github stellt eine von den Machern von Git betriebene zentrale Plattform für Projekte dar, über die alle gleichberechtigt an Projekten arbeiten können ohne das jemand die speziell maintainen muss. Fast jedes Projekt auf Github hat etliche Forks über die dann meisst auch Code zurückfliesst.

Subversion setzt immer einen Zentralen Server voraus den jemand Maintainen muss. Um etwas beisteuern zu können muss man immer den Maintainer anbetteln. Änderungen die der Community u.U. gefallen werden vom Maintainer aus persönlichen gründen abgelehnt.
An Subversion Repositores kann man nicht offline arbeiten, man kann ohne Server keine älteren Stände "auschecken" oder mehrere Commits ohne Server entwickeln. Oder gar ganze Branches. Selbes gilt für CVS.

rudolfkoenig

Subversion kann man auch lokal aus dem Dateisystem betreiben, dass es nicht ueblich ist, ist eine andere Sache. Es geht mir gar nicht um die git vs. subversion Diskussion (sourceforge bietet git an), sondern um die sourceforge vs. github vs. andere Alternative. Mit github habe ich die gleichen Probleme, wie mit sourceforge (und vorher Berlios): wenn der Besitzer meint, es geht auch mit weniger Betreuung oder Hardware, damit der Shareholder- Value steigt, dann hat man keinen Einfluss darauf, ausser weiterzuziehen.
Ich bin z.Zt. auf der Suche nach der "anderen Alternative", und nein, ich brauche dafuer keine Hilfe, sondern Zeit.

Prof. Dr. Peter Henning

Komisch. Ich habe in den Jahren, in denen ich FHEM benutze und dafür entwickele, noch niemals einen Maintainer "anbetteln" müssen oder gar erlebt, dass jemand anders dies hätte tun müssen. Oder erleben müssen, dass irgendeine als sinnvoll anerkannte Änderung nicht übernommen wurde.

Schlussfolgerung: An den Haaren herbeigezogene Scheinargumente. Also lasst es endlich gut sein - oder macht Euren eigenen Laden auf.

LG

pah

Wernieman

Was hält Ihr davon den Thread zu schließen?

bedaurlicherweise wird die SVN vs GIT Diskussion mittlerweile (nicht nur hier) wie ein Glaubenskrieg geführt.

Wenn der Threadersteller es will, kann er ja auf GIT forken .... und sich wundern, wenn die Hauptentwickler nicht mitziehen, das der Folk tot wird ;o)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Prof. Dr. Peter Henning

Sag ich doch: Sie sollen ihren eigenen Laden aufmachen.

LG

pah

Kuzl

Zitat von: Prof. Dr. Peter Henning am 17 Juni 2015, 22:26:17
Komisch. Ich habe in den Jahren, in denen ich FHEM benutze und dafür entwickele, noch niemals einen Maintainer "anbetteln" müssen oder gar erlebt, dass jemand anders dies hätte tun müssen. Oder erleben müssen, dass irgendeine als sinnvoll anerkannte Änderung nicht übernommen wurde.

Das hab ich schon anders erlebt, als ich für eins deiner Module eine Änderung vorgeschlagen habe.

Prof. Dr. Peter Henning

Anbetteln ? Lächerlicher Unsinn.

Ich habe einen Vorschlag erhalten, und ihn als nicht sinnvoll abgelehnt.

pah

Kuzl

Zitat von: chris_z am 17 Juni 2015, 17:42:25
Änderungen die der Community u.U. gefallen werden vom Maintainer aus persönlichen gründen abgelehnt.
Meiner Meinung nach trifft es das aber ganz gut zumal ich bis heute keinen Grund erhalten habe, was dagegen spricht.

Aber um zum Thema zurückzukommen:
Die Idee ohne Maintainer zu arbeiten ist evtl. ganz nett, allerdings bin ich mir nicht ganz sicher, ob das so gut ist. Wenn ein Problem mit einem Modul auftaucht das nicht einfach zu lösen ist, fühlt sich unter Umständen keiner dafür verantwortlich.

Und wenn man bei Git die commits annehmen oder ablehnen muss, sind wir genau so weit wie jetzt, denn patches kann ja jeder vorschlagen.

Viele Grüße,
Kuzl

rudolfkoenig

Es passiert oefters, dass ein Patch eine bisherige, aber dem Patch-Autor unbekannte Funktionalitaet dupliziert oder kaputtmacht. Oder eine beabsichtigte zukuenftige Entwicklung des Moduls erschwert. Es braucht einen, der alle Features kennt, und im Problemfall entscheidet.

moonsorrox

Zitat von: betateilchen am 19 Mai 2015, 21:29:45
Sobald Rudi sich mit git auskennt und dann grünes Licht gibt, könnte die Entwicklung komplett umziehen. Prinzipiell ist bereits alles vorhanden, lediglich das direkte commiten in das git repository ist noch nicht freigegeben. Das git repository wird derzeit noch regelmäßig aus dem svn migriert.

https://git.fhem.de

Eine Userverwaltung wird man aber auch weiterhin brauchen - egal ob git oder svn.

hier existiert es nicht mehr, ist Fhem umgezogen.?
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

viegener

Zitat von: moonsorrox am 22 Oktober 2015, 13:47:46
hier existiert es nicht mehr, ist Fhem umgezogen.?

FHEM ist immer noch auf sourceforge, das "offizielle" github repository, dass von sourceforge gespiegelt wird ist meines Wissens nach:
https://github.com/mhop/fhem-mirror

Johannes
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können