Roadmap Community-Firmware V1.0

[MasterOfGizmo]

Wie schon ein paarmal geschrieben bin ich hier nicht derjenige, der bestimmt was passiert und was nicht, Dass wir hier alle etwas unterschiedliche Ziele verfolgen ist auch normal, immerhin hat da jeder so seinen persönlichen Use-Case, auf den er hin arbeitet. Aber genau dafür gibt es ja Forks. Du kannst in Deinem Zweig ungehindert Deinen Ideen nachgehen, ich in meinem. Und wenn es für irgendwas einen Konsens gibt kann man es auch in das Hauptrepository übernehmen.

Wenn Du möchtest, dass die offizielle Firmware bestimmte Funktionen erhält und sich in eine bestimmte Richtung entwickelt und Du derjenige bist, der das gerne koordinieren möchte, dann arbeite ich gerne weiter an meinem eigenen Fork und Du übernimmst die Arbeiten am offiziellen Zweig. Das habe ich mehrfach angeboten, aber auch das bestimme nicht ich einfach so. Sobald sich hier eine Mehrheit für ein "ja, bitte lasst Raphael die Koordination des Hauptrepositories übernehmen" ausspricht werde ich Dir volle Schreib- und Admin-Rechte geben.

Wenn das am Ende dazu führt, dass einer von uns nur noch an seinem eigenen Fork arbeitet ist das m.E. auch kein Problem. Dann arbeitet er entweder eh an den Wünschen der Mehrheit vorbei und die Mehrheit wird ihn ignorieren oder die Mehrheit wendet sich diesem Fork zu. Auch das wäre dann in keiner Weise ein Problem sondern gelebte Demokratie.

Aber man kann das nicht erzwingen. Das ist ein Hobby und jeder darf und soll es so machen, wie er mag. Und wenn es z.B. mir nicht gefällt, was Du mit dem Apps-Repository machst, dann ziehe ich meine Apps in ein anderes Repository um. Das ist dann halt so ...

[PHabermehl]

Jungs,
als - was die fw-Entwicklung betrifft - Außenstehender wollte ich mich aus Diskussionen in dieser Richtung eigentlich raushalten, aber jetzt kann ich es mir doch nicht verkneifen...

Zunächst mal finde ich es beeindruckend, was die Community leisten kann. Wenn man die überraschten Reaktionen von TXT-Besitzern sieht, die zum ersten Mal über die cfw stolpern, dann ist das eine massive Bestätigung dafür, daß die cfw auf dem richtigen Weg ist und daß dafür auch Bedarf und Interesse weit über den Einzelnen hinaus besteht.

Und genau deshalb sollten sich die Beteiligten im Klaren sein, daß es eben nicht nur reines Hobby eines jeden Einzelnen ist, sondern daß nach außen hin die cfw als Ganzes Erwartungen weckt, was bei Enttäuschung nicht nur auf die community, sondern auf das ganze ft-Universum zurückfällt. Das erklärt sicher auch die Zurückhaltung seitens ft, wenn es um die cfw geht...

Daher denke ich, daß die cfw tatsächlich etwas mehr Planung und Koordination bräuchte. Die Frage nach einer Roadmap halte ich für absolut berechtigt. Und dazu gehört, daß festgelegt wird, welche Features enthalten sein sollen, daß für einzelne Features auch Verantwortliche auf den Zettel kommen und daß Terminvorgaben gemacht werden. Irgendwann muß man den Sack mal zumachen, sonst wird es keine stable releases mehr geben.
Es ist sicherlich eine Herausforderung, aus einem Haufen Alphatiere verschiedensten Alters ein geordnetes Rudel zu machen, daß gemeinsam in die selbe Richtung rennt, aber wenn die cfw nicht als Scherbenhaufen enden soll, ist das m.E. durchaus nötig. Leider kommen da dann - Stichwort Alphatier - wieder persönliche Befindlichkeiten ins Spiel. Das ist genauso verständlich wie problematisch, muß aber irgendwie doch überwunden werden.

Bedenkt doch bitte auch den durchaus limitierten Produktlebenszyklus des TXT. Der ist nämlich schon zur Hälfte abgelaufen. Aus diesem Grund ist es für mich absolut inakzeptabel, daß Brickly als Vorzeigeprojekt in einem bereits absolut nutzbaren Zustand NICHT Bestandteil der cfw bzw. nicht über den offiziellen App-Store erhältlich sein soll und darauf verwiesen wird, daß da ja dann "irgendwann noch" RoboBlocks kommen soll, während RoboBlocks selbst aus verständlichen Gründen bei seinem Autor wiederum u.a. auch wegen der Existenz von Brickly so niedrig priorisiert wurde, daß im Moment keine Aussagen zur Verfügbarkeit getroffen werden können.

Das Dumme dabei: Es gibt schon seit Langem Bedarf für eine solche Einsteiger-IDE. Es gibt bereits erste Interessenten, die diese IDE - Brickly - im schulischen Umfeld nutzen möchten. Es gibt Interessenten, die den Bedarf so einschätzen, daß sie durch die Erstellung von Tutorials den Einstieg erleichtern wollen, und das alles wird dann durch die Idee, Brickly "irgendwann" offiziell durch RoboBlocks zu Ersetzen, ad absurdum geführt?
Brickly ist schon viel zu weit, um es unter der Tischdecke zu halten, und es macht m.E. auch keinen Sinn, die Entwicklungsarbeit 2x zu leisten.

Meine Bitte, ganz ausdrücklich an Richard und Till:
Eure Arbeit ist spitze und extrem wertvoll, für die community, für fischertechik, für einen ganzen Haufen von Anwendern!
Wäre es vorstellbar, daß Till den Status von Brickly überdenkt und TouchUI - GERNE mit scrollendem Launcher! - und Brickly als seine Babys weiter supportet, so daß es für Dritte Sinn macht, längerfristig mit Brickly zu planen, während Richard ein klein wenig mehr Koordination - verbunden mit der dazugehörenden Kommunikation - für die cfw übernimmt und die Konkurrenzsituation Brickly-RoboBlocks nochmal überdenkt? Noch ist nicht zu viel Zeit in RoboBlocks geflossen, und m.E. wäre Richards Einsatz an anderer Stelle wesentlich wichtiger.
Mit einer sauberen CFW1.0, Brickly, Python und C als Entwicklungsumgebungen, der Möglichkeit, auch RoboPro weiter zu verwenden und einer (nach außen hin, halbwegs, im Rahmen der Möglichkeiten) geschlossen in einer Richtung agierenden community könnte man dann evtl. auch fischertechnik selbst davon überzeugen, daß ein TXT2 mit leistungsstärkerem ARM-Prozessor, evtl. mehr RAM und wertigerem Touchscreen (größer, evtl. höher auflösend, sensitiver/reaktiver) softwareseitig abwärtskompatibel zu cfw bleibt (siehe Raspberry 2 -> 3), so daß der cfw eine längere Zukunft beschieden ist und sich der Einsatz Aller dann auch über die Jahre auszahlt.

So, das wollte ICH jetzt mal gesagt haben. ICH habe den TXT nach langem Zögern ausschließlich wegen der cfw und wegen Brickly angeschafft, meine Kinder waren erst mit Brickly für die Robotik zu begeistern und ich denke, wir alle haben unsere Verbindung zu fischertechnik und möchten letztlich zum Erhalt und Ausbau des Systems beitragen, weil es uns eine Herzenssache ist. Gemeinsam.

Peter

[PHabermehl]

Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Ja, gesehen und würde ich auch unterstützen. Eine zentrale Konfig-App, statt hier ein bisschen, da ein bisschen...

[ski7777]

Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Ja, gesehen und würde ich auch unterstützen. Eine zentrale Konfig-App, statt hier ein bisschen, da ein bisschen...

Das habe ich schon oft gesagt, bin da aber gegen eine Wand gerannt.

Raphael

[MasterOfGizmo]

Das habe ich schon oft gesagt, bin da aber gegen eine Wand gerannt.

Dann auch hier die Bitte, dann aber die Verantwortung für das resultierende Tool zu übernehmen. Für mich selbst habe ich nun hierarchische Ordnerstrukturen im Launcher, damit ich eben alle Settings-Apps in einem Settings-Ordner habe. Wenn ihr stattdessen lieber eine eigene App haben wollt ist das absolut legitim. Mir persönlich ist der Audwand zur Zeit zu groß, so eine All-in-One-App zu pflegen da dort ja auch noch Bluetooth, Bluetooth-IP, USB-Netz etc ect dazu käme.

Aber wie gesagt: Wenn einer die Hand hebt und ab jetzt für so ein All-in-one-Tool verantworltich sein will, dann bekommt er entsprechenden Zugriff auf's Hauptrepository und kann loslegen. Ich selbst halte die aktuelle kleine Menge einzelner Tools für besser wartbar. Aber das liegt im Auge des Betrachters.

Wer übernimmt es?

[LarsKusch]

Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Ja, gesehen und würde ich auch unterstützen. Eine zentrale Konfig-App, statt hier ein bisschen, da ein bisschen...

Das habe ich schon oft gesagt, bin da aber gegen eine Wand gerannt.
Raphael

Ich wäre dafür dass wir einen Kompromiss finden, und uns nicht gegenseitig beleidigen, sondern eine Lösung finden, die:

1. alle Möglichkeiten die der TXT(und evtl. Nachfolger) ausnützt
2. alle User (vorallem die Community (Mehrheit)) gut findet, mit der aber auch alle leben müssen.
3. die eine sinnvolle, gleichmäßig und faire Verteilung der Aufgaben auf die Entwickler ermöglicht und die Chance gibt ungefähr nachzuvollziehen wann, was kommt.

Evtl. sollten sich sogar alle FT-CFW Entwickler an einen Tisch setzen einmal gescheit aber ordentlich diskutieren und dadurch eine für alle akzeptable Lösung finden?
Soweit meine Meinung

Hochachtungsvoll,
Lars

[richard.kunze]

als - was die fw-Entwicklung betrifft - Außenstehender wollte ich mich aus Diskussionen in dieser Richtung eigentlich raushalten, aber jetzt kann ich es mir doch nicht verkneifen...

Wieso "als Außenstehender"? Du bist doch schon mitten drin in der CFW-Entwicklung.

Und genau deshalb sollten sich die Beteiligten im Klaren sein, daß es eben nicht nur reines Hobby eines jeden Einzelnen ist, sondern daß nach außen hin die cfw als Ganzes Erwartungen weckt, was bei Enttäuschung nicht nur auf die community, sondern auf das ganze ft-Universum zurückfällt.

Da muss ich jetzt allerdings sagen: Egal ob die CFW jetzt "Erwartungen weckt" oder nicht, für mich ist es trotzdem ein Hobby. Das mach ich in meiner Freizeit. Unbezahlt. Und genau deswegen mache ich das auch in dem Umfang, und zu den Zeiten, und auf die Art wie ICH das will.

Wenn das nicht so wäre, dann würde sich die Arbeit an der CFW nämlich nicht wesentlich von meinem ganz normalen Job unterscheiden. Mit dem klitzekleinen Unterschied, dass normalerweise meine Kunden einen vierstelligen Betrag pro Tag dafür bezahlen, dass ich für sie nach ihren Wünschen Software entwickle.

Daher denke ich, daß die cfw tatsächlich etwas mehr Planung und Koordination bräuchte. Die Frage nach einer Roadmap halte ich für absolut berechtigt. Und dazu gehört, daß festgelegt wird, welche Features enthalten sein sollen, daß für einzelne Features auch Verantwortliche auf den Zettel kommen und daß Terminvorgaben gemacht werden.

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

Aber ganz bestimmt keine Terminvorgaben. Um es nochmal ganz deutlich zu sagen: Das hier ist ein Hobbyprojekt, das in der Freizeit der Beteiligten erstellt wird. Da sind irgendwelche Ansprüche und Forderungen nicht wirklich angebracht.

Und damit jetzt aber auch genug Rant.

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.

Eure Arbeit ist spitze und extrem wertvoll, für die community, für fischertechik, für einen ganzen Haufen von Anwendern!
Wäre es vorstellbar, daß Till den Status von Brickly überdenkt und TouchUI - GERNE mit scrollendem Launcher! - und Brickly als seine Babys weiter supportet, so daß es für Dritte Sinn macht, längerfristig mit Brickly zu planen, während Richard ein klein wenig mehr Koordination - verbunden mit der dazugehörenden Kommunikation - für die cfw übernimmt und die Konkurrenzsituation Brickly-RoboBlocks nochmal überdenkt? Noch ist nicht zu viel Zeit in RoboBlocks geflossen, und m.E. wäre Richards Einsatz an anderer Stelle wesentlich wichtiger.

Das sehe ich ähnlich. Brickly ist auf jeden Fall gut genug um es zu verwenden (sieht man ja auch am Echo hier im Forum), und ich habe in der CFW auch noch jede Menge anderer Baustellen offen ohne jetzt unbedingt sofort RoboBlocks weiter bauen zu müssen. Und die Arbeit an Brickly ist wäre ja auch nicht umsonst auch wenn es irgendwann mal RoboBlocks gibt - das ist nämlich letztendlich auch nicht viel anderes als eine Kombination von Brickly und BrickMCP fest in die CFW eingebaut..

[richard.kunze]

Hat jemand meine letzten Beitrag gesehen?
Was haltet ihr davon?

Ja, gesehen und würde ich auch unterstützen. Eine zentrale Konfig-App, statt hier ein bisschen, da ein bisschen...

Ich fände es da besser, wenn es für die getrennten Aspekte der Konfiguration auch jeweils passende Konfig-Apps gibt, die man dann in einer gemeinsamen Kategorie im Launcher zusammenpackt. Vor allem angesichts der Tatsache, dass man das mit dem neuen "Launcher V2" von Till schön machen kann, und dass die App-Startzeiten (gerade für System-Apps) mit den von mir skizzierten "Apps Light" auch kein Thema mehr sind.

Bei "der einen zentralen Konfig-App" sehe ich die Gefahr, dass man da Zeug zusammenschmeißt das thematisch einfach nicht zusammengehört. Oder - um den Kram zu strukturieren - dieselbe Funktionalität wie im Launcher grade nochmal neu erfindet. Oder beides...

[PHabermehl]

Sehr gute Argumente, eine "Config-"Gruppe im Launcher v2 und die Configs als App-light würde ich für eine sehr gute Lösung halten.

[ski7777]

Sehr gute Argumente, eine "Config-"Gruppe im Launcher v2 und die Configs als App-light würde ich für eine sehr gute Lösung halten.

Das ist eine gute Idee.

Raphael

[PHabermehl]

Wieso "als Außenstehender"? Du bist doch schon mitten drin in der CFW-Entwicklung.

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.

Da muss ich jetzt allerdings sagen: Egal ob die CFW jetzt "Erwartungen weckt" oder nicht, für mich ist es trotzdem ein Hobby. Das mach ich in meiner Freizeit. Unbezahlt. Und genau deswegen mache ich das auch in dem Umfang, und zu den Zeiten, und auf die Art wie ICH das will.

Das wollte ich auch gar nicht in Frage stellen. Ich denke mal, wir machen das alle unbezahlt und in unserer Freizeit. Was ich meinte, ist, daß wir uns TROTZDEM über die Außenwirkung im klaren sein müssen.

Wenn das nicht so wäre, dann würde sich die Arbeit an der CFW nämlich nicht wesentlich von meinem ganz normalen Job unterscheiden. Mit dem klitzekleinen Unterschied, dass normalerweise meine Kunden einen vierstelligen Betrag pro Tag dafür bezahlen, dass ich für sie nach ihren Wünschen Software entwickle.

Hmmmmm.... wenn ft sich solche SW-Entwickler leisten würde, hätten sie eine vorzeigbare Firmware, aber der TXT wäre nicht mehr bezahlbar. 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

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

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.
Jeweils nach einem release wird im devel ein feature freeze durchgeführt, der gefreezede Stand wandert nach "rc", der ehemalige "rc" logischerweise in "stable" und ... weiter gehts.

Davon unabhängig kann ja jeder forken, wo und was er will......

Daher -> GitHub.

Aber ganz bestimmt keine Terminvorgaben. Um es nochmal ganz deutlich zu sagen: Das hier ist ein Hobbyprojekt, das in der Freizeit der Beteiligten erstellt wird. Da sind irgendwelche Ansprüche und Forderungen nicht wirklich angebracht.

Wiederum Innenwirkung vs. Außenwirkung... Unter Außerachtlassung der genauen Umstände möchte ich auf eine Aussage wie "Der TXT ist so absolut unbrauchbar!" im Zusammenhang mit der cfw verweisen. Die Details spielen keine Rolle, aber wer bei einer Recherche zum TXT oder der cfw auf eine solche Aussage stößt, der wird wohl eher abgeschreckt. Also, was öffentlich zugänglich ist, sollte auch funktionieren. Evtl. ist da eine deutlichere Trennung zwischen release und development notwendig. Und was die Terminvorgaben betrifft, war ich zu unpräzise. Das soll keine Verpflichtung sein, sondern ein selbstgestecktes Ziel, daß das Abschätzen eines release-Zeitpunktes ermöglicht.

Und damit jetzt aber auch genug Rant.

Ich sehe das nicht als rant, es war von meiner Seite eine Reihe von Gedanken, die mich seit geraumer Zeit bewegten und die ich mal zur Diskussion stellen wollte. Wenn ich einstimmige Meinungen hören will, frage ich meine Kinder, ob Mama kochen soll oder wir lieber mal wieder gemeinsam einen Döner essen wollen

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.

Und die Arbeit an Brickly ist wäre ja auch nicht umsonst auch wenn es irgendwann mal RoboBlocks gibt - das ist nämlich letztendlich auch nicht viel anderes als eine Kombination von Brickly und BrickMCP fest in die CFW eingebaut..

Um BrickMCP ist es nicht wirklich schade, ich bitte meinen Kommentar nicht diesbezüglich falsch zu verstehen. 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. Brickly und RoboBlocks parallel weiterzuentwickeln bindet unnötige Ressourcen. 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.

So, und jetzt nochmal ganz ausdrücklich DANKE AN ALLE FW-BETEILIGTEN, bitte versteht meine Äußerungen nicht als Negativ-Kritik. Meine Motivation rührt hauptsächlich daher, daß ich im Moment gerne Lokalisierung und USB-Schreibrechte hätte, und zwar so, daß auch andere ANWENDER davon profitieren, d.h., daß man die cfw nicht selber bauen muß, um die ganzen neuen features zu bekommen. Das bedingt einen 0.9.3er release, und dafür fehlen noch ein paar Kleinigkeiten, wenn ich richtig verstanden habe...

So, an dieser Stelle für mich Ende des Themas, damit das nicht zu weite Kreise zieht und am Ende wirklich noch jemand beleidigt ist.

Gruß
Peter

[ski7777]

Also,
Vileicht ging es so:

Code: Alles auswählen

from wlan import setup as wlans
from lang import setlang
from bt import setup as btsetup

Und in der wlan.py

Code: Alles auswählen

def setup():
#Code der Wifi-App

Und?

Ganz so einfach ist das auch wieder nicht
Und zum anderen haben wir ja bereits eine Lösung

[MasterOfGizmo]

Meine Fähigkeiten und mein Wissen reichen bei weitem nicht aus, um mir das anzumaßen.r

Na, komm. Ich finde Deine Beiträge wirklich toll. Wir übrigen kochen auch nur mit Wasser ...

[ski7777]

Stimmt.
Als Ordner zu.machen ging auch.
Der Launcher 2 ist ja fertig.
Man könnte ihn ja einbauen.
Oder was meint ihr?

Wenn das ganze fertig ist, wird MoG das sicher einbauen, wenn es da keine Einwände gibt. Schön wäre es, wenn die Settings Apps direkt in einem Unterordner von "System" zusammengefasst werden.

Raphael

[richard.kunze]

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.

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

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

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

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

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?

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

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

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.

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]

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

[PHabermehl]

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

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:

[richard.kunze]

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

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.

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:

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

[ThomasW]

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

Bitte Richard nicht vergessen (richard.kunze)

[MasterOfGizmo]

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.