fhem auf github?

[robin13]

Ich sehe in der Entwicklung section das es eine komplizierte Liste von wer berechtigungen auf welche Module hat... und es sieht so aus als ob man sich aufwendig beantragen usw. muesste...  waere es moeglich das Projekt auf github umzuziehen, und dann sowas schoen mit Pull Requests abwickeln?

[rudolfkoenig]

Ich kenn mich mit git noch nicht aus. Wer wuerde die Pull Requests beantworten?

[justme1968]

ich glaube immer noch nicht das git im aktuellen entwicklungsmodell wirklich einen vorteil hat.

die 'berechtigungen' sind nur policy und umgangston und nicht tatsächliche rechte.

[betateilchen]

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.

[peterchen89]

Mit github könnte jeder github Nutzer Pullrequests öffnen unabhängig von irgendwelchen Rechten auf dem Repo. Die können dann öffentlich diskutiert und verbessert werden. Das dürfte die Einstiegshürden für neue Entwickler schon ein ganzes Stück senken. Die Nutzer mit Rechten auf dem Repo könnten die dann akzeptieren und mergen. Wieso man meint die GIT Umgebung für ein open source Projekt selbst aufsetzen zu müssen kann ich nicht so recht nachvollziehen.

[rudolfkoenig]

Danke fuer die Erklaerung. Ich habe verstanden, dass abgesehen vom Namen und etwas anderen Befehlsfolgen keinen Unterschied zu einem hier geposteten diff gibt.

Zum selbst aufgesetzten Repository: wir haben immer wieder Probleme mit sourceforge: der Zugriff ist nicht immer vorhanden, aber immer langsam, die Moeglichkeiten sind begrenzt, die Daten werden mAn auf der falschen Seite der Erde gespeichert, und die Geldgeber koennen jederzeit auf die Idee kommen, das Ganze einzustellen oder einfach soweit runterzupriorisieren, dass die Leute freiwillig gehen. Sourceforge gegen einem anderen Dienst auszutauschen, der prinzipiell die gleichen Probleme hat, finde ich vertane Zeit, das habe ich mit Berlios->Sourceforge schon einmal durchgemacht.

[Prof. Dr. Peter Henning]

Ich sehe keine Hürden für Entwickler im derzeitigen Modell.. Ganz im Gegenteil sichert das gegenwärtige Verfahren die Qualität in nicht unerheblichem Umfang - das ginge komplett verloren, wollte man umstellen.

LG

pah

[Wernieman]

Da ich bisher mit beiden Systemen schon gearbeitet habe ... GIT ist eine Möglichkeit mit eigenen Problemen, nicht "die Lösung auf alles".

Da ich (als Systemadministrator) beruflich auch eher auf dem Standpunkt stehe: "Never Change a Running System",  und da die Weiterentwicklung von FHEM mit dem jetziegen Model läuft, weiß ich nicht, ob ein Switch auf GIT unbedingt alles verbessert.

P.S. githup is eben nicht nur GIT, sondern GIT + Erweiterungen zum Workflow. Gerade im Semiprofessionellen Bereich der Softwareentwicklung, wie eben auch bei FHEM, ist die Einhaltung des Workflow das Problem. Ein Programmierer versteht es, aber jemand, der noch nie damit zu tun hatte ....

[wa]

Github bietet halt eine einfache Möglichkeit auch kleine Dinge schnell zu melden/verbessern und darüber öffentlich diskutieren zu lassen.

Die Platform ist jetzt mittlerweile so populär, dass Google sogar Google Code zugunsten von Github einstellt. Deren Server sind meiner Erfahrung nach auch deutlich schneller...

Nichtdestotrotz wird man sich etwas in den Git-Workflow einarbeiten müssen, aber die Hürden für contributions sind meiner Erfahrung nach einfach deutlich geringer.

Dem dort vorhanden Mirror https://github.com/mhop/fhem-mirror werden ja auch schon Pull-Requests/Issues gemeldet, die halt nur nie/selten den Weg in die offizielle Codebase finden...

[Prof. Dr. Peter Henning]

Es ist gut, dass die Hürden für "kleine Verbesserungen" derzeit etwas höher sind. Sonst kommt nämlich jeder zweite Newbie gleich mit hundert Änderungen, die SEIN System besser machen. Und was Google tut oder lässt, sollte man niemals zum Anlass eigenen Handelns machen.

LG

pah

[wa]

Es bestünde halt auch die Möglichkeit, dass FHEM dadurch auch international etwas populärer wird, immerhin gibt es nicht gerade wenig Konkurrenz in dem Bereich.

Wenn man es halt elitärer halten möchte - gut, dass ist auch eine mögliche Entscheidung. Die Qualität der Pull-Requests erkennt man übrigens meist sehr schnell und Angst vor hunderten unsinnigen Newbie-Änderungen muss man da auch nicht unbedingt haben. Im Zweifel kann man sie ja auch einfach ignorieren.

Die Reputation von Sourceforge ist (neben der Geschwindigkeit) ja auch mittlerweile leider nicht mehr unbedingt die beste: http://www.golem.de/specials/sourceforge/

Andererseits, wenn ihr mit dem bisherigen Prozess sehr zufrieden seid, dann halt nicht.

[Hauswart]

Ich fände Github auch eine coole Sache, klar werden mehr Entwickler Anpassungen vorschlagen.
Ich wahrscheinlich auch, die Hemmschwelle - mich derzeit in Sourceforge usw. einzuarbeiten ist mir zu hoch - daher habe ich bisher noch keine Code-Anpassungen vorgenommen.

[Prof. Dr. Peter Henning]

Oh Leute   

@wa: "Es bestünde halt auch die Möglichkeit", soso. Na, dann schlage ich doch mal vor, dass "wa" sich auszeichnet, indem er im englischsprachigen Forumsteil Support leistet. Wenn alle anderen dann feststellen, dass das wunderbar läuft, wird man das sicher noch mal überdenken können.

@Hauswart: Was um Himmels willen soll denn eine "Einarbeitung in Sourceforge" sein ? Das Einzige, was man als FHEM-Autor neben der Perl-Programmierung beherrschen muss, ist der Eintrag einer URL in einen SVN-Client. Absolut faule Ausrede also, seine eigene Abstinenz damit zu begründen, dass der Code nicht auf einer "coolen" Plattform gehostet wird.

LG

pah

[justme1968]

das gebaren von sourceforge nicht zu unterstützen und deshalb zu wechseln wäre ein argument das ich nachvollziehen kann.

aber alles andere: verdreht das nicht ein bisschen die tatsachen?

und wenn tatsächlich die hemmschwelle - sich die zwei oder drei nötigen kommandos für das werkzeug (egal ob cvs, svn oder git) anzueignen - zu hoch ist sollte man vielleicht auch den rest gar nicht erst anfassen...

[herrmannj]

Ohne da sicher zu sein: Github unterstützt keine server side hooks. Die gehen soweit ich weiss nur lokal. Das was da angeboten wird sind webhooks

Vg
Joerg

[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]

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.

[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)

[Prof. Dr. Peter Henning]

Sag ich doch: Sie sollen ihren eigenen Laden aufmachen.

LG

pah

[Kuzl]

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]

Ä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]

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

[viegener]

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

[moonsorrox]

ich hatte schon danach gesucht und auch einige "githubs" hier aus dem Forum gefunden.

Hintergrund war ich suche ein Modul welches in keinem der /contrib Zweige war, deshalb eben hier die Frage. Aber auch in dem github von herrmannj ist das Modul nicht.

Ich frage mal im entsprechenden Thread den Modulautor, der das 74_AMAD.pm bereitgestellt hat