Roadmap Community-Firmware V1.0

[MasterOfGizmo]

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.

[MasterOfGizmo]

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.

[ski7777]

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

[MasterOfGizmo]

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.

[ski7777]

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

[MasterOfGizmo]

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.

[ski7777]

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

[ski7777]

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

[ski7777]

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

[MasterOfGizmo]

Hi Leute,
Wann soll 0.9.3 rauskommmen?

Sobald jemand Lust und Zeit hat, ein neues Release zu machen. Das kannst Du wenn Du magst auch selbst tun. Nimm Dir den aktuellen Stand, teste, ob alles akzeptabel funktioniert und mach' einen Release. Es gibt da keinen Fahrplan und vor allem gibt es kein "ihr". Community bist Du genauso wie jeder andere.

Im Prinzip könnte jetzt sofort jemand ein Release machen. Da spricht technisch nichts dagegen, so wie ich das gerade sehe. Ich persönlich würde allerdings noch das Erscheinen der neuen BT-Geräte abwarten und dann nehmen wir den Support für die noch mit auf. Das kann aber genauso gut in 0.9.4 kommen. Es gibt da echt keine Regel und keinen Fahrplan und wer nicht warten mag ist eingeladen, es sofort selbst zu machen.

[PHabermehl]

Danke, Till

[richard.kunze]

Hallo zusammen,

ich habe unter https://github.com/ftCommunity/ftcommun ... ilestone/3 mal angefangen, die Punkte zusammenzutragen die wir für Version 0.9.3 meiner Meinung nach noch angehen sollten. Wer will: Schaut bitte mal drüber, kommentiert, bringt Eure eigenen Punkte da mit rein, und (ganz wichtig ) weist Euch die Sachen zu die Ihr umsetzen wollt.

Liebe Grüße,

Richard

[PHabermehl]

Klasse!

Jetzt wollt' ich gerade auf einem Laptop debian installieren, meine Frau hat's gerade auf die letzte Sekunde verhindert - sie hat die gesamte Buchführung vom Schulförderverein ausgerechnet auf die Kiste gezogen, natürlich keine Backups irgendwo...
Ob ich jetzt doch mal entgegen meiner Überzeugung debian in ner virtual box unter Suse laufen lasse? Mal schauen...

[ski7777]

weist Euch die Sachen zu die Ihr umsetzen wollt

Wäre ich Mitglied der dev Gruppe, würde ich das machen.

Raphael

[PHabermehl]

Hallo zusammen,

nachdem mein cfw-build-Rechner jetzt wunderbar läuft, kam mir der Gedanke, ob es ggf. Sinn macht, öffentliche, unverbindliche Beta-Builds anzubieten?

Nicht jeder kann und will die fw selbst bauen, aber vielleicht könnte man den Testerkreis noch etwas vergrößern.

Man könnte doch jeweils ein paar snapshot-builds (unter Angabe von Datum und commit-Stand der sources) auf GitHub ablegen.
Ich würde diesen Weekly-Build-Service übernehmen und dafür sorgen, daß jeweils der aktuelle und zwei Vorgängerstände zum Download bereitstehen.

Was meint Ihr dazu?

Gruß
Peter

[ski7777]

Ich baue zwar hier auch alles selbst, fände das aber sehr gut. Falls erforderlich würde ich auch immer was beisteuern.

[richard.kunze]

nachdem mein cfw-build-Rechner jetzt wunderbar läuft, kam mir der Gedanke, ob es ggf. Sinn macht, öffentliche, unverbindliche Beta-Builds anzubieten?
Nicht jeder kann und will die fw selbst bauen, aber vielleicht könnte man den Testerkreis noch etwas vergrößern.

Gute Idee.

Man könnte doch jeweils ein paar snapshot-builds (unter Angabe von Datum und commit-Stand der sources) auf GitHub ablegen.

Wie würdest Du das im Detail machen wollen?

Mein Vorschlag: Leg es auch als Release auf Github, aber nimm als Versionstag dann sowas wie "<CFW-VERSION>+snapshot-<YYYYMMDD>" (für einen Snapshot heute also "0.9.3-rc+snapshot-20170322"). Das würde dann auch mit der für 0.9.3 geplanten Update-App gut zusammenspielen - die würde dann nämlich die Snapshots nicht automatisch als Update anbieten, aber wenn man einen Snapshot installiert hat trotzdem ein Upgrade auf das nächste "offizielle" Release vorschlagen (zu den Details warum das mit dem vorgeschlagenen Versionierungsschema so funktioniert siehe http://semver.org/).

Außerdem kann man Releases auf Github auch noch als "Pre-Release" markieren, das würde dann auch gleich nochmal anzeigen dass da gegebenenfalls mit Fehlern zu rechnen ist.

Ich würde diesen Weekly-Build-Service übernehmen

Klasse, danke!

und dafür sorgen, daß jeweils der aktuelle und zwei Vorgängerstände zum Download bereitstehen.

Ich denke wir können die Weekly-Builds genausogut auch auf Github liegen lassen.

[ski7777]

In der Update App könnte man dann auch auswählen, dass man eine Prerelease installieren will.

Raphael

[PHabermehl]

@ Richard:

Ja, so machen wir das! Evtl. melde ich mich nochmal per PM, um die Details zu klären, wie und wo das auf github hinsoll, dann heißt es demnächst: Friday is firmware day

Ich finde auch den Vorschlag von Raphael gut - warum soll man im Update-Manager nicht die Option haben, daß man auch den weekly build installieren kann, mit entsprechendem Warnhinweis versehen?

Gruß
Peter

[richard.kunze]

Ja, so machen wir das! Evtl. melde ich mich nochmal per PM, um die Details zu klären, wie und wo das auf github hinsoll, dann heißt es demnächst: Friday is firmware day

OK, klasse. Die Absprache können wir gerne auch hier im Forum machen (dann aber besser in einem eigenen Thread). Vielleicht interessiert es ja den einen oder anderen wie man sowas aufsetzen kann.

Github hat übrigens auch eine API um Releases zu erstellen (siehe https://developer.github.com/v3/repos/releases/) - der ganze Release-Prozess sollte sich daher eigentlich auch ganz gut automatisieren lassen.