[Freifunk Franken] Protokoll Techniktreffen 06.02.2016

So Feb 7 22:22:28 CET 2016

Am Sonntag, den 07.02.2016, 22:07 +0100 schrieb Christian Dresel:
> Guten Abend
> 
Abend zusammen

> Am 07.02.2016 um 14:46 schrieb delphiN:
> > Am 06.02.2016 22:05, schrieb Tim Niemeyer:
> >> Das ganze müsste mit dem Tag gelöst sein, denn am Tag kann ja 
> >> unmittelbar abgelesen werden was drin ist und was nicht.
> > 
> > Wenn ich das richtig verstanden habe besteht die Version in
> > Zukunft dann also immer aus Zeitstempel und Git-Tag? Also z.B. so 
> > "20160207-g68314ea"? Das wäre natürlich eindeutig und damit ok.
> > Nur Datum alleine geht meiner Meinung nach aber nicht.
> 
> ich glaube angedacht war eher:
> 
>     YYYYMMDD-[Anzahl commits]-[Commit-ID]
>     YYYYMMDD-alpha
>     YYYYMMDD-beta
>     YYYYMMDD
> 
Ich hab das in der Reihenfolge geschrieben, in der der Release Ablauf
ist.
1. Zeile ist alles was Heimbuilds sind und nicht offiziell released wird
4. Zeile ist ein final/stable release

> alpha und beta ist klar, bin mir jetzt nur nicht sicher wie wir das
> mit dem Final besprochen hatten. 1. oder letzter Punkt?
> 
> > 
> > Falls der unwahrscheinliche Fall eintritt und ein einem Datum
> > mehrere Releses gemacht werden müssen (z.B. weil beim ersten
> > Release irgend etwas ganz schief gelaufen ist oder spät Abends noch
> > ein wichtiges Update kam) dann wird es halt für den Benutzer
> > schwierig auseinanderzuhalten welches jetzt die aktuellere Version
> > ist. Zu erwarten, dass Benutzer in das Git-Log schauen ist mMn
> > unrealistisch.
> 
> geb ich dir recht, aber ich glaube nicht das dies passieren wird. Wir
> haben uns (sofern ich mich recht erinnere) dazu entschlossen das als
> Datum das letzte Patch das eingeschlossen ist verwenden. Also wenn
> heute release kommt und das letzte Patch aber von vorgestern ist,
> kommt der Datum von vorgestern rein. Jetzt stellen wir nach dem
> Release fest, da ist was kaputt, patchen es und releasen erneut, würde
> ja der heutige Datum drinnen landen. Ich denke mit etwas gesunden
> Menschenverstand und Aufmerksamkeit bekommt man das schon hin.

> > 
> > Außerdem wird man anhand des Datums nicht erkennen können ob es
> > sich um ein reines Bugfix-Release oder um ein Major-Release
> > handelt, dass evtl. sogar inkompatiebel zu alten Versionen ist.
> 
> da war unser Hauptproblem bei MAJOR.MINOR.PATCH. Wann ist denn etwas
> inkompatibel damit MAJOR um 1 hoch geht? Geändertes Batman (Meshen
> geht nicht mehr)? Geänderter VPN (meshen geht noch aber VPN nicht
> mehr, als Meshrouter weiterhin nutzbar)? kein Netmon mehr?
> Routermodell XY wird aufgrund mangelnder Leistung nicht mehr
> untersützt? Es sind immer einzelne Funktionen hier inkompatibel aber
> dennoch irgendwo kompatibel. Das ist alles irgendwie nicht ganz leicht
> zu definieren. Das war (so wie ich es verstanden habe) der Hauptgrund
> der Änderung.
> 
Das ist genau der Punkt weshalb wir uns dafür entschieden haben. Wir
haben nicht die Men-Power um eine Api fest zu definieren und um mögliche
Interpretationen zu vermeiden eben nicht Major.Minor.Patch
@delphin: Du schreibst ja selbst, du würdest diese Nummern nutzen um
mögliche Inkompatiblitäten zu erkennen. Da wir nicht 100% sicherstellen
können, das dies nicht der Fall ist, eben nicht dieses Schema.

> > Hätte man diese Information z.B. in der Versions-Nummer könnte
> > z.B. ein autoupdater (irgendwann mal) anhand der Versionummer
> > entscheiden ob automatisch upgedated wird oder nicht. Patches
> > könnten dann z.B. sofort eingespielt werden, major-releases nur
> > manuell.
> 
> Autoupdater wird es nicht geben, angedacht war im WebUI ein Fenster
> "hey du User da vorm Monitor am Server gibts ne neue Version update
> doch mal - hier klicken für Update oder manuell hier herunterladen -
> Patchnote findet sich hier".
> Erkennen kann man es ganz leicht, man prüft ob die Version am Router
> unterschiedlich zu der am Server ist. Da am Server immer die neuste
> liegt, ist bei Unterschied eine neue Version drausen und das
> Updatefenster kommt zum Vorschein. Angedacht war dazu eine Version
> Datei im Firmwareroot wo die Version drinnen steht (ist am wenigstens
> zum downloaden und besser als ein ganzes Dic-Listening zu scannen)
> 
@delphin: Hier haben wir auch kurz deinen Patch diskutiert und waren uns
einig, das die meisten Ansätze davon sinnvoll sind. Es gab ja schon
einige Anmerkungen dazu, wenn diese gefixt sind, entspricht das soweit
auch unseren Vorstellungen.
Falls du keine Lust hast, das entsprechend anzupassen, sag bitte
Bescheid, dann kann das jemand anders übernehmen.
> > 
> > Man sollte sich vielleicht nochmal kurz die Zeit nehmen und
> > komplett zu Ende diskutieren ob es wirklich sinnvoll ist ein
> > anderes Versionierungs-Schema zu verwenden als alle mit bekannten
> > Packet-Manager.
> 
> das haben wir eigentlich gemacht und ich habs jetzt auch begründet
> warum, ich hoffe ich habs etwa so rüber gebracht wie beim treffen
> besprochen wenn nicht lass ich mich gerne korrigieren. Auch hör ich
> mir gerne deine Meinung dazu an.
> 
@delphin: Wir haben das fast ne Stunde diskutiert und haben am Ende
gemeinschaftlich diesen Entschluss gefasst. Die Anmerkungen die du
hattest, waren ebenfalls alle im Gespräch. Wenn es Dinge gibt, die wir
noch nicht bedacht hat, immer her damit.

Viele Grüße
Jan

> mfg
> 
> Christian
> 
> > 
> > Das wollte ich nur zu bedenken geben. Nicht, dass wir die 
> > Versionierung dann in ein paar Monaten wieder komplett anpassen
> > müssen. MAJOR.MINOR.PATCH-ZUSATZ oder etwas ähnliches erscheint mir
> > immer noch der bessere Ansatz zu sein (rein sachlich
> > argumentiert).
> > 
> > Gruß, delphiN
> > 
> > _______________________________________________ franken mailing
> > list franken at freifunk.net 
> > http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> > 
> 
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net