RF1000 hat geschrieben:die aktuelle GitHub Struktur zielt darauf ab, dass auch Anwender damit zurecht kommen die keine Programmierkenntnisse haben.
Ich denke, wenn man zwei Branches für RF1000 und für RF2000 hat, wäre es nicht weniger Anwenderfreundlich. Es gibt ein Drop-Down-Menü, um zwischen den Branches zu wechseln, außerdem könnte man einfach beide Links posten.
Wenn jemand einen RF1000 hat dann findet er alles für sein Gerät im RF1000 Ordner und wenn jemand einen RF2000 hat dann findet er alles für sein Gerät im RF2000 Ordner.
Das gilt auch für Branches. Sogar besser noch, man hat jeweils einfach nur einen der beiden Ordner und muss nicht unnötig den anderen jeweils mit auschecken.
Wenn sich jemand mehr mit den Sourcen beschäftigt dann sind diese identisch (sie unterscheiden sich nur durch den MOTHERBOARD Eintrag in der Configuration.h der angibt, ob diese Sourcen für den RF1000 oder für den RF2000 kompiliert werden sollen).
Das stimmt noch, sobald ich anfange für den RF1000 etwas zu modifizieren, ist diese modifikation im RF2000 Verzeichnis nicht vorhanden. Jemand muss dann von Hand alle Änderungen in das andere Verzeichnis einpflegen.
Für die Versionskontrolle sollte es doch egal sein, ob "RF1000" und "RF2000" Verzeichnisse oder Branches sind.
Das wäre bei svn so, bei git jedoch nicht. Bei git kann ich nicht ohne Weiteres zwischen Verzeichnisen mergen.
Da beide Verzeichnisse immer gleichzeitig und auf den gleichen Stand aktualisiert werden erfahren Sie die selben Änderungen und bekommen die gleichen Änderungs-Logeinträge.
Das passiert aber eben nicht automatisch. Wenn ich in meinem Fork etwas in das RF1000 Verzeichnis committe, bleibt das RF2000 Verzeichnis unverändert. Damit laufen die beiden Versionen irgendwann auseinander.
Bei uns intern gibt es auch nur einen Stand der Firmware, der auf GitHub in zwei Verzeichnisse veröffentlicht wird.
Wenn ihr eine von meinen Änderungen dann irgendwann übernehmen wollt, wird's schwierig. Mit einer korrekten Verzeichnis- und Branch-Struktur wäre das kein Problem, ich würde euch einfach einen Pull-Request senden. Was passiert, wenn ich euch Pull-Requests für das RF1000 und jemand anderes Pull-Requests für RF2000 schickt, die aber gegenseitig Konflikte hervorrufen? Das müsst ihr dann alles von Hand wieder auseinanderklamüsern. Wenn es Branches wären, würde git euch das weitgehend abnehmen.
Wir warten noch auf eine Entscheidung darauf, inwieweit bzw. in welcher Form die Community bei der Weiterentwicklung der Firmware eingebunden werden kann. Denkbar wäre ja z.B. die aktuelle Master-Struktur so beizubehalten und nur mehr einen Stand im Development-Branch zu haben, an dem auch die Community mitarbeiten kann. Ich rechne aber nicht vor Januar mit einer entsprechenden Entscheidung.
Aktuell verhindert ihr auch umgekehrt, dass ich einfach einen Fork auf github anlege und in diesem weiterentwickle. Wenn ihr euch an die git-Konventionen haltet, müsst ihr sonst nichts weiter machen. Jeder kann Forks anlegen und trotzdem problemlos eure Änderungen wieder integrieren. Dafür ist GitHub ja schließlich gedacht
Genau das habt ihr ja auch mit eurer Firmware gemacht, die ist doch auch nur ein Fork von der originalen Repetier-Firmware. Die Verzeichnisstruktur im Repository habt ihr jetzt aber völlig verdreht, dann wird es auch schwierig, die Verbindung zum upstream noch vernünftig zu halten... Vielleicht soll ja mal eine Änderung von euch wieder zurück in die offizielle Version?
Ein Konfigurationsprogramm der Firmware mit einigen wenigen Parametern die einem die Headerdateien richtig parametrisiert wäre schon ein Schritt in die richtige Richtung. Der Kunde geht auf eine Webseite stellt ein "Ich habe einen RF1000 oder 2000, mit oder ohne Fräse mit Dual oder ohne etc. pp. blablabla drückt auf einen Knopf FW download und die haut er dann mit Adurino auf den RF1000. Wobei das schon für echte Anfänger eine Herausforderung sein kann. Bitte jetzt nicht sagen dass das nicht geht. Die Repetierseite hat ja so einen Konfigurator, der nur leider überladen mit Fragen und Parametern ist, die einen RFx000 Nutzer herzlich wenig interessieren bzw überhapt etwas sagen. 
