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