Roadmap Community-Firmware V1.0

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
richard.kunze
Administrator
Beiträge: 556
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Roadmap Community-Firmware V1.0

Beitrag von richard.kunze » 01 Mär 2017, 22:23

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.
Stell da mal Dein Licht nicht unter den Scheffel. Das, was ich bisher von Dir gesehen habe, hat mir zumindest ganz gut gefallen.
Und - wie Till auch schon gesagt hat - wir kochen hier alle nur mit Wasser.
PHabermehl 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 :mrgreen:
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 abhaben :|
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.
So ein Setup ist (zumindest aktuell) denke ich ein paar Nummern zu groß (und damit auch zu kompliziert).

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 :D

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).
Je länger ich darüber nachdenke, desto sinnvoller finde ich die letzte Option (einzelne Issues auf github, mit Tags/Milestone als "Klammer"). Aber so ganz sicher bin ich mir da immer noch nicht - was meint Ihr dazu?
PHabermehl hat geschrieben:
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.
Da ist es sicher oft weniger das Wollen als das Können... Sich nebenbei und unentgeltlich zum Fachinformatiker weiterzubilden, will ja auch nicht jeder.
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: Um BrickMCP ist es nicht wirklich schade, ich bitte meinen Kommentar nicht diesbezüglich falsch zu verstehen.
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: 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.
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 :-)).

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

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.

olagino
Beiträge: 90
Registriert: 02 Aug 2014, 13:13
Kontaktdaten:

Re: Roadmap Community-Firmware V1.0

Beitrag von olagino » 01 Mär 2017, 22:32

Ich würde auch zu der dritten Variante tendieren, das ist meiner Meinung nach von den drei Varianten die übersichtlichste unter Einbetracht der Randbedinungen.


Liebe Grüße,

olagino

Benutzeravatar
PHabermehl
Moderator
Beiträge: 1777
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: Roadmap Community-Firmware V1.0

Beitrag von PHabermehl » 01 Mär 2017, 22:37

Na dann sage ich mal, die Diskussion hat doch ne Menge gebracht :mrgreen:

Nach kurzem Nachdenken finde ich die Idee, die Roadmap als getaggte Einzel-Issues auf GitHub zu pflegen, ganz charmant... Kann man da dann irgendwo ein Dashboard anlegen, daß die wichtigsten Infos (issues für v0.9.3: gesamt/offen/in progress/closed) usw. anzeigt?

Ich dachte da an sowas, geklaut von atlassian jira: :mrgreen:
Bild
Moderative Beiträge sind explizit gekennzeichnet!

richard.kunze
Administrator
Beiträge: 556
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Roadmap Community-Firmware V1.0

Beitrag von richard.kunze » 01 Mär 2017, 23:10

olagino hat geschrieben:Ich würde auch zu der dritten Variante tendieren, das ist meiner Meinung nach von den drei Varianten die übersichtlichste unter Einbetracht der Randbedinungen.
PHabermehl hat geschrieben: Nach kurzem Nachdenken finde ich die Idee, die Roadmap als getaggte Einzel-Issues auf GitHub zu pflegen, ganz charmant...
OK, dann machen wir das so. Ich hab eben mal einen passenden Milestone "v0.9.3" angelegt, dem man die Issues dann zuordnen kann.
PHabermehl hat geschrieben: Kann man da dann irgendwo ein Dashboard anlegen, daß die wichtigsten Infos (issues für v0.9.3: gesamt/offen/in progress/closed) usw. anzeigt?

Ich dachte da an sowas, geklaut von atlassian jira: :mrgreen:
Bild
So schön geht das wohl leider nicht. Aber immerhin kann man nach dem Milestone filtern, und im Header der Ergebnis-Liste sieht man wieviele offene/geschlossene Issues zu diesem Milestone gehören: https://github.com/ftCommunity/ftcommun ... ilestone/3

nq30
Beiträge: 144
Registriert: 25 Feb 2017, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von nq30 » 02 Mär 2017, 07:52

Welche Entwickler Arbeiten an der CFW?
Ich habe bis jetzt nur folgende gesehen:
MasterOfGizmo
ski7777

Und noch was:
Wo kann man mithelfen?
Meine möglichkeiten wären:
Übersetzen en-de
Simple Programmierug(py)
Wiki pflegen
Auch manche Sachen Dokumentieren

Meldet euch wenn ihr mich braucht :D
Mit freundlichen Grüssen
nq30

ft:cool :)

ThomasW
Beiträge: 177
Registriert: 08 Mär 2012, 15:02
Wohnort: St. Gallen

Re: Roadmap Community-Firmware V1.0

Beitrag von ThomasW » 02 Mär 2017, 08:22

nq30 hat geschrieben:Welche Entwickler Arbeiten an der CFW?
Ich habe bis jetzt nur folgende gesehen:
MasterOfGizmo
ski7777
Bitte Richard nicht vergessen (richard.kunze)

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 02 Mär 2017, 09:19

ski7777 hat geschrieben:Schön wäre es, wenn die Settings Apps direkt in einem Unterordner von "System" zusammengefasst werden.
Das kann man recht einfach durch eine mitgelieferte /opt/ftc/.launcher.xml lösen, hat aber einen Haken, der m.E. dagegen spricht: Das wäre nicht übersetzbar. So ein Order würde dann in allen Sprachen "Settings" heissen. Sicher kann man auch da wieder eine Speziallösung drumrum stricken, aber das ist es m.E. nicht wert.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 02 Mär 2017, 09:28

Was ist mit dem VNC? Zur Zeit ist eine halbfertige Lösung drin, die wohl so gut wie niemand benutzt. Ich habe eine noVNC-basierte Lösung drumrum gebaut. M.E: sollte das alles entweder mit rein oder aber es sollte alles komplett raus.

Damit man das nutzen kann muss der Launcher etwas Code dazu laden und die Qt-Bibliotheken dürften mit VNC-Support auch etwas größer sein, so dass VNC-Support etwas längere TXT-Startzeiten und etwas mehr Speicherverbrauch bedeutet. Eine Möglihckeit das abschaltbar zu machen haben wir bisher nicht, ich weiss auch nicht, was da alles in die Qt-Bibliotheken fest eingebaut ist und sich gar nicht abschalten lässt.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 02 Mär 2017, 09:34

Dritte Baustelle auf meiner Seite ist Bluetooth-LE. Für den WeDo-2.0-Hub reicht das, was ich bisher gebaut habe. Ich würde noch den neuen BT-Controller abwarten und dann dafür sorgen, dass der aus der CFW mit einer entsprechenden App angesprochen werden kann, vielleicht auch aus Brickly raus :-)

Dazu parallel die Frage: Was machen wir mit Test-Apps und Demo-Code? Im Store finde ich das nicht unbedingt gut aufgehoben, da ich nicht plane diese Apps immer aktuell zu halten und zu supporten. Ist mehr so ein "schau mal, so ging das mal, vielleicht hilft es dir ja"-Ding. Aber das heisst auch, dass die nach irgendwelchen API-Änderungen einfach nicht mehr gehen werden und ich die ggf. auch nicht reparieren werde. Das kollidiert also etwas mit der User-Erwartung, die Peter schon angesprochen hat.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Roadmap Community-Firmware V1.0

Beitrag von ski7777 » 02 Mär 2017, 09:37

Hiersiehst du eigentlich sehr gut, wie das ganze funktioniert.
Um den VNC Server abzuschalten könnte man einfach die Zeile

Code: Alles auswählen

export QWS_DISPLAY="multi: LinuxFb:/dev/fb0:0 VNC:0"
in der

Code: Alles auswählen

/etc/init.d/rcS
auskommentieren. Da wäre vergleich bar mit https://github.com/ski7777/ftcommunity- ... 6b2bb2cbba

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 02 Mär 2017, 09:58

Aber den Code hast Du doch fest in die Qt-Bibliotheken einkompiliert. Mit dem Switch schaltest Du das zwar ab, aber ob da auch nur ein Byte weniger Daten geladen werden wissen wir nicht.

Ich wäre dafür VNC komplett zu entfernen.
Zuletzt geändert von MasterOfGizmo am 02 Mär 2017, 10:00, insgesamt 1-mal geändert.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Roadmap Community-Firmware V1.0

Beitrag von ski7777 » 02 Mär 2017, 10:00

Die mulitilib und die VNC lib sind in der aktuellen Konfiguration fester Bestatndteil von qt. Ob wir durch einen derartigen switch RAM sparen könnte man ausprobieren.

Raphael

Benutzeravatar
MasterOfGizmo
Beiträge: 1822
Registriert: 30 Nov 2014, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von MasterOfGizmo » 02 Mär 2017, 10:02

ski7777 hat geschrieben:Die mulitilib und die VNC lib sind in der aktuellen Konfiguration fester Bestatndteil von qt. Ob wir durch einen derartigen switch RAM sparen könnte man ausprobieren.
Genau darum geht es ja. Haufenweise Sachen beim Start zu laden, die dann nur wenige Leute je nutzen führt dazu, dass wir irgendwann ein langsames aufgeblasenes System haben.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

nq30
Beiträge: 144
Registriert: 25 Feb 2017, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von nq30 » 02 Mär 2017, 13:58

Stimmt.
Mein TXT hat ja auch die cfw und er startet sehr langsam(nicht als beleidigung nehmen)
Mit freundlichen Grüssen
nq30

ft:cool :)

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Roadmap Community-Firmware V1.0

Beitrag von ski7777 » 02 Mär 2017, 14:01

nq30 hat geschrieben:Stimmt.
Mein TXT hat ja auch die cfw und er startet sehr langsam(nicht als beleidigung nehmen)
wie lange dauert es denn? Wenn du die 0.9.2 hast, hat das nichts mit VNC zu tun. Der TXT ist ein Computer auf dem Stand von vor 10 Jahren mit einem sehr vollem aktuellen Betriebssystem. Das das nicht von jetzt auf gleich da ist, ist normal.

Rapahel

nq30
Beiträge: 144
Registriert: 25 Feb 2017, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von nq30 » 02 Mär 2017, 14:03

Achso
Dann ist es klar
Mit freundlichen Grüssen
nq30

ft:cool :)

nq30
Beiträge: 144
Registriert: 25 Feb 2017, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von nq30 » 02 Mär 2017, 14:59

Hi Leute,
also es ist hier ja ein Thread für cfw1.0?
Weil ich so beiträge über 0.9.3 sehe
Stört das euch?
Mit freundlichen Grüssen
nq30

ft:cool :)

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Roadmap Community-Firmware V1.0

Beitrag von ski7777 » 02 Mär 2017, 15:09

Ob der der Thread nun 0.9.3, 0.9.1 oder 0815 heißt ist doch ganz egal. Es geht hie rum die nächste stable Version und alle der beteiligten wissen das.

Raphael

nq30
Beiträge: 144
Registriert: 25 Feb 2017, 07:44

Re: Roadmap Community-Firmware V1.0

Beitrag von nq30 » 02 Mär 2017, 16:25

Hi Leute,
Wann soll 0.9.3 rauskommmen?
Mit freundlichen Grüssen
nq30

ft:cool :)

Benutzeravatar
ski7777
Beiträge: 844
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Roadmap Community-Firmware V1.0

Beitrag von ski7777 » 02 Mär 2017, 16:36

nq30 hat geschrieben:Hi Leute,
Wann soll 0.9.3 rauskommmen?
Wenn alles fertig ist, was wir haben möchten, das stabil läuft und wir damit zufrieden sind.

Raphael

Antworten