Stell da mal Dein Licht nicht unter den Scheffel. Das, was ich bisher von Dir gesehen habe, hat mir zumindest ganz gut gefallen.PHabermehl hat geschrieben: Meine Fähigkeiten und mein Wissen reichen bei weitem nicht aus, um mir das anzumaßen. Wenn ich mal einen erfolgreichen Build auf die Reihe kriege, sehen wir weiter.
Und - wie Till auch schon gesagt hat - wir kochen hier alle nur mit Wasser.
Der Tagessatz kommt ja nicht 1:1 bei mir an - davon wollen noch Büro, Verwaltung, Geschäftsführung usw. bezahlt werden. Und der Staat will natürlich auch was davon abhabenPHabermehl hat geschrieben: Und wenn ich solche Tagessätze bekäme, würde ich mir eine persönliche firmware in Indien erstellen lassen und in meiner Freizeit nur noch Anwender sein
So ein Setup ist (zumindest aktuell) denke ich ein paar Nummern zu groß (und damit auch zu kompliziert).PHabermehl hat geschrieben:richard.kunze hat geschrieben:Eine Roadmap fände ich ebenfalls nicht schlecht. Von mir aus auch noch mit einer Aufstellung, wer welche Aufgaben übernehmen will. Da ist die Frage denke ich eher, wie man das im Detail organisieren will (auf Github? Hier im Forum?).PHabermehl hat geschrieben: Ich denke da im Detail an folgendes:
- einen "release candidate" branch, in dem nur noch bugfixing im Hinblick auf das release betrieben wird. Dazu gehörte dann auch eine buglist und die Nennung des Bearbeiters. Wer dann unterstützen möchte, weiß, an wen er sich wenden muß. Außerdem ließe sich dann bei Interesse zumindest ungefähr abschätzen, wie weit ein release noch entfernt ist...
- einen "stable" branch, in dem das jeweils letzte release als Quelle und als fertiger Build liegt
- einen "devel" branch, in dem die neuen features integriert werden können.
Für Releases tuns im Moment auch schlichte Tags (und für die Binaries die "Release"-Funktion von Github, die auf eben jenen Tags aufbaut) - einen "stable branch" brauchen wir da erst, wenn wir für ein bestehendes Release ein spezielles Bugfix-Release herausbringen wollen, das eben nicht einfach alle Neuerungen aus dem aktuellen master enthalten soll (und wenn wir den stable branch dann brauchen, ist der auch schnell vom zugehörigen Tag weggeforkt).
Und den Codefreeze vor einem Release können wir - zumindest im Moment - auch genausogut direkt in master machen. So viele Entwickler sind wir jetzt auch wieder nicht, dass wir da die Truppe in ein QA-Team (die sorgen dafür das der RC funktioniert) und ein DEV-Team (die dürfen sich derweil weiter in "devel" austoben) spalten müssten...
Wenn wir irgendwann mal zweistellige Entwicklerzahlen haben, dann können wir uns über Formalismen Gedanken machen
Eigentlich wollte ich auch auf eine Frage raus, die ein paar Größenordnungen kleiner und konkreter ist: Wie und wo genau organsieren wir die Roadmap für Version 0.9.3? Zur Auswahl hätten wir:
- Einen passenden Thread hier im Forum. Vorteil: Gut sichtbar, Kommentare sind einfach machbar. Nachteil: Schwierig zu pflegen (nur der ursprüngliche Autor kann Anpassungen vornehmen wenn sich etwas ändert).
- Ein "Roadmap"-Issue auf Github. Hat dieselben Vor- und Nachteile wie der Foren-Thread, aber man kann direkt auf Commits und auf Github-Benutzernamen Bezug nehmen. Nachteil (gilt auch für alles weiter): Ist halt auf Github, und damit für "reinen Foristen" nicht ganz so leicht zugänglich.
- Eine Roadmap-Seite im Wiki auf Github. Wäre denke ich leichter zu pflegen als die beiden ersten Alternativen.
- Für jeden Eintrag in der Roadmap ein eigenes Issue, und das Ganze dann mit passenden Tags (z.B. "Roadmap" und "v0.9.3") und "Milestones" "zusammengeklammert". Kann schön einfach gepflegt werden, man kann gut notieren wer was bearbeitet, aber den "großen Überblick" anzuzeigen könnte da etwas sperrig werden (geht aber eventuell auch - da müsste man mal mit den Filtermöglichkeiten für Issues rumspielen).
Das braucht man ja auch gar nicht. Auch wenn man keine Zeile Code schreiben kann (oder will): Dokumentieren, Wiki pflegen, Fragen beantworten, Übersetzen usw. sind mindestens ebenso wichtige Aufgaben (wenn nicht sogar noch wichtiger).PHabermehl hat geschrieben:Da ist es sicher oft weniger das Wollen als das Können... Sich nebenbei und unentgeltlich zum Fachinformatiker weiterzubilden, will ja auch nicht jeder.richard.kunze hat geschrieben:Bzw. fast, und mit einer etwas positiveren Note: Die CFW lebt vom Mitmachen. Und wer mitmacht, der kann auch beeinflussen in welche Richtung die CFW geht und wie schnell die CFW weiterentwickelt wird. Von daher: Beteiligt euch. Macht mit. Das ist der schnellste und einfachste Weg Eure Wünsche an die CFW umzusetzen.
Ich hatte dabei eher die Projektverwaltungs-Funktionen im Sinn, die Brickly (zum Teil bewusst) nicht hat und die BrickMCP dann "nachrüstet" - die sind in RoboBlocks dann natürlich auch dabei (auch wenn die Details dann bestimmt etwas anders aussehen).PHabermehl hat geschrieben: Um BrickMCP ist es nicht wirklich schade, ich bitte meinen Kommentar nicht diesbezüglich falsch zu verstehen.
Da brauchst Du dir denke ich keine Sorgen machen. Vom "Look and Feel" (d.h. den verfügbaren Blöcken usw.) wird sich Brickly und RoboBlocks nicht großartig unterscheiden, und auch "unter der Haube" (d.h. bei der Umsetzung von Blockly-XML nach Python) gibt es denke ich keinen Grund, da was radikal anders zu machen als Brickly (ganz im Gegenteil - ich habe fest vor, mich da schamlos bei Brickly zu bedienen ).PHabermehl hat geschrieben: Es geht um mit Brickly erstellte Projekte bzw. evtl. sogar auf Brickly aufbauende Lernkonzepte mit entsprechendem Lehrmaterial (->Tutorials, Dokumentationen, Beispielprogramme etc.)
Wenn man den TXT mit cfw neben vergleichbaren Lego-Produkten sehen möchte, würde ich Kontinuität über Integrationsgrad stellen. So schön die Idee einer oder mehrerer fest integrierte IDEs in der cfw auch ist, wenn der Brickly-RoboBlocks-Übergang für die Anwendermehrheit einen harten Bruch darstellen würde, wäre das ein massiver Nachteil.
Und natürlich werde ich (oder wer auch immer an RoboBlocks entwickelt - das Teil muss nicht unbedingt eine Ein-Mann-Show sein) auch darauf achten, möglichst keine bestehenden Anwendungen kaputtzumachen.
In der Hinsicht sind wir denke ich mit einem Linux als Basis so oder ganz gut aufgestellt. Den größten Teil der CFW braucht man für eine andere Linux-taugliche Hardware eigentlich lediglich neu zu übersetzen.PHabermehl hat geschrieben: Und dann droht ja irgendwann der ft-seitige Bruch in Form eines TXT-Nachfolgers, wobei ich mir da ja wie schon erwähnt sehr sinnvoll ein Prozessor-Upgrade unter Gewährleistung einer firmwareseitigen Abwärtskompatibilität vorstellen könnte. Ob das jemand bei ft auch so sieht, kann ich nicht beurteilen.
Wirklich Arbeit sollten da eigentlich nur die TXT-spezifische IO-Ansteuerung machen (und die ist in ftrobopy eigentlich ganz gut gekapselt), und natürlich die Integration von RoboPro (dafür lassen wir auf dem TXT einfach die Software aus der Original-Firmware laufen).
Mit anderen Worten: Wenn Fischertechnik einen TXT-Nachfolger herausbringt der ebenfalls auf Linux aufsetzt, dann wird die CFW da vermutlich auch sehr schnell drauf laufen.