Title: immer für alle Targets bauen oder nur für die bei denen sich was geändert hat?
Post by: BO_Andy on 24. November 2018, 14:38:06
Bootloder 5.0.1 geht auf Tex Eagle 5.0.2 kann ich nicht testen da es denn nicht für denn Eagle gibt
LG BO_Andy |
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: DF8OE on 24. November 2018, 15:47:18
Richtig. der 5.02 ist eine reine Sache für den OVI40 H7.
vy 73
Andreas |
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: DL8EBD on 24. November 2018, 17:05:07
| EDIT EDIT: 5.0.2 is out and works on all machines including H7 as expected. |
|
Dann ist das aber nicht korrekt... |
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: peter_77 on 24. November 2018, 19:12:38
Zumal es den (fehlerhaften) 5.0.1 ja für den mcHF gibt ?!
Kommt der 5.0.2 jetzt noch für mcHF oder ist der 5.0.1 dafür OK.
Verwirrung komplett ???
|
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: DB4PLE on 24. November 2018, 20:08:13
Hallo,
um die Konfusion komplett zu machen: Für den mcHF und F7 sind 5.0.2 und 5.0.1 identisch (bis auf die Versionsnummern). Deswegen hat sich Andreas entschlossen, für diese Plattformen keinen 5.0.2 bereitzustellen.
Ich bin damit nicht einverstanden, weil es aus meiner Sicht die ganze Kommunikation komplizierter macht und man nicht mehr weiß, was jetzt aktuell ist. Deswegen würde ich hier um ein Meinungsbild bitten:
1. Immer für alle Plattformen die jeweilige Version bereitstellen, auch wenn es mal bedeutet, das keine Änderung für die jeweiligen Geräte enthalten sind
2. Bei den Versionen schauen, ob auch wirklich eine Änderung enthalten ist und damit zeitweise unterschiedliche Versionsnummer als die jeweils aktuelle haben.
Ich bin klar für 1), das macht es für alle Beteiligten einfacher, beim Vergleichen von Versionsnummer und Problemen.
Niemanden zwingt einen ja, jede Version mitzunehmen, aber es git immer nur einen neueste Version, die für alle identisch ist.
Da ich aber nur für mich und meine Erfahrungen spreche, sollten vielleicht mal die Betroffenen zu Wort kommen, also die Nutzer und Nichtentwickler.
Was ist Eure Meinung?
73
Danilo
|
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: BO_Andy on 24. November 2018, 20:52:26
| Ich bin der Meinung das beide Versionen denn gleichen nahmen haben sollten um nicht für verwirrungrn zu sorgen hatte die 5.0.2 auch geflahst und dann ging nix mehr |
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: DF5LI on 24. November 2018, 21:29:57
Ich habe gerade eine Installationsorgie hinter mir. 2x mcHF, 2x F7, 1x H7. Jeweils den aktuellen Bootloader und die FW.
Ich gehe immer so vor, dass ich auf der OV I40 Seite unter "Modifikationen" nach unten scrolle und dann auf die aktuellen Stände klicke. Heute musste ich beim BL 5.0.2 in der Historie zurück gehen, um den BL 5.0.1 für die mcHFs und die F7 zu laden. Das finde ich störend, deshalb bin ich für Danilo's Vorschlag Nr.1. Nicht jeder Betreiber eines mcHF oder OVI40 liest regelmäßig im Github und im Forum mit, um den Überblick über die Versionen zu behalten. Deshalb halte ich es für sinnvoll, die jeweils funktionierenden BL und die FW auf der Modifikationen-Seite an erster Stelle zu finden. Auch auf die Gefahr hin, dass einige Versionsstände keine Änderungen mitbringen.
Die Updateaktion hat übrigens gut funktioniert, alle Geräte laufen ohne erkennbare Fehler. |
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: DL8EBD on 24. November 2018, 21:34:54
ich bin für "2"
gibt es beispielsweise nur für den F7 eine neue Version, dann hat diese eben eine neuere Versionsnummer - alle anderen bleiben so wie sie sind.
Warum sollten sich die Versionsnummern der anderen Plattformen mit ändern obwohl sich bei denen inhaltlich nichts getan hat?
Macht doch keinen Sinn.
Davon ab, wenn ich nach neuen Updates schaue, gucke ich nur in der für mich relevanten Rubrik!
Nutze ich nur H7, dann schaue ich doch nicht nach was beim mcHF eventuell neues dabei ist.
So gesehen kann es nicht passieren dass man versehentlich einen H7 Bootloader in ein mcHF System flasht
|
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: BO_Andy on 24. November 2018, 21:53:02
| Harry genau so ist es mir auch ergangen ich habe drauf geklickt und nicht geschaut und schon war es zu spät. |
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: OE3HKC on 24. November 2018, 22:05:20
Hi,
Bootloader werden sich ja nicht so oft ändern wie die FW...
deshalb finde ich eine BL-Versionsgleichbenennung für H7 und den Rest der Hardware nicht als unbedingt zwingend..
allerdings.... bei Firmware-Änderungen wäre es sicher wünschenswert, auch weiterhin das gewohnte System beizubehalten, auch wenn die Änderung nur eine Gruppe betrifft...
vy 73,
Helmut |
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: F4HTX on 25. November 2018, 06:48:04
Hello Friends,
Everything back to normal behaviour overhere, congratulations for the great job.
mchf : 413:1007h / 5.0.2 /2.9.74
ovi40 : 451:1001h / 5.0.2 /2.9.74
73's
François |
Title: Re:Please upgrade your UHSDR bootloaders to 5.0.1
Post by: BO_Andy on 25. November 2018, 17:19:48
Alles super bootloder über dfu modus auf 5.0.2 installiert danach Update über USB getestet 2.9.74 Reboot nach ziehe des USB sticks funktioniert.
Teszgerät TRX Eagle. Ihr habt wieder super Arbeit geleistet besten Dank
LG BO_Andy |
Title: Losgelöste Builds oder immer für alle Plattformen bauen?
Post by: DF8OE on 26. November 2018, 07:53:33
Die Websachen für einen individuellen Build sind weit fortgeschritten und prinzipiell kurz vor einem möglichen Einsatz. Wenn ihr ins Hauptverzeichnis (https://www.amateurfunk-sulingen.de/uhsdr/) geht seht ihr dort schon etliche .txt-Dateien in denen die verfügbaren Versionen für alle Plattformen und gesplittet nach Firmware/Bootloader aufgelistet sind. Diese Dateien werden von meinem Build-Automaten gepflegt - es ist kein händischer Eingriff nötig.
Wenn losgelöste Builds tatsächlich angeboten werden soll in der Produktionsphase eine Tabelle für jede Plattform im Web zu erreichen sein, die eine individuelle Histrory für jede Plattform aufbaut und anklickbare Links zu den Versionen enthält. Gibt es eine Version für eine Plattform nicht, erscheint diese Version auch nicht in der History. Die Ordnerstruktur auf dem Server braucht dafür nicht angefasst zu werden. Es muß nur noch ein kleines php-Script "davor" das diese Funktionalität bereitstellt.
Der jetzige losgelöste Build für den BL des H7 war eine Panne auf meiner Seite. Ich hatte wegen eines Bugfixings in meinem Buildscript diesen Automaten vergessen wieder auszuschalten - für den Bugfix musste ich mit voller Funktionaiität testen - sorry dafür.
Die Idee (bzw. in meinen Augen sogar die Notwendigkeit) von losgelösten Versionsnummern kam mir als wir wieder mal recht tief in der Softwareanpassung für den OVI40 waren. Es sind dort etliche Builds auch für den mcHF released worden, bei denen sich definitiv nichts geändert hat. Ich fand es wenig produktiv, dass alle mcHF'ler jedesmal neu geflasht haben obwohl sich für die nichts geändert hat. Und der Stand dass genau dieses Szenario immer wieder aufkommen wird (auch für Firmwarefeatures die nur auf den größeren MCUs laufen) fand (und finde) ich den Ansatz von losgelösten Builds nach wie vor besser. Allerdings kann ich Danilos Einwände absolut nachvollziehen - denke aber, dass unsere Klientel (Funkamateure) dieses Schema im Gegensatz zu normalen Verbrauchern versteht.
Ich bin für beide Versionen offen - habe aber damals (vor ~6 Monaten) alles auf meiner Build-Seite schon für losgelöste Builds vorbereitet und einsatzbereit. Es müsste nur noch das Webinterface dafür zusammengenagelt werden - das schätze ich auf 2...3 Stunden Gesamtarbeit. Also absolut kein Problem.
Die Lösung im Fall von starken Entwicklungen für den OVI40 mit einem getrennten Branch zu arbeiten favorisiere ich nicht so stark - weil die Anpassungen für die Builds auf meiner Seite nicht so einfach zu automatisieren sind und es dabei mit der Versionierung ebenfalls zu Problemen kommt - vermutlich sogar zu noch größeren. Es müsste ein zweites Versioning für diese Plattformen aufgebaut werden - also im Prinzip für jede Plattform ein eigener Branch. Das kommt dann auch mit der Pflege der Software wieder in Bedrängnis. Der Aufwand parallele Branches zu synchronisieren ist in meinen Augen nicht einfacher als die Lösung nicht immer für alle zu bauen.
Mein Favorit sind losgelöste Versionen (== es gibt nicht für alle Plattformen alle Versionsnummern, erkenntlich wäre das aus der Webtabelle). Nur, wenn sich etwas für die Plattfom geändert hat, gibt es eine neue Version. Tut sich für eine Plattform nichts, wird die UHSDR-Version zwar weitergezählt, aber für einzelne Plattformen gibt es "Löcher" im Versionsschema.
Die Iabelle würde rückwirkend starten können - schaut selbst in die Textdateien wann es losgegangen ist. Ich denke der Aufbau der Textdateien ist selbsterklärend...
vy 73
Andreas |
Title: Re:Losgelöste Builds oder immer für alle Plattformen bauen?
Post by: DL8EBD on 26. November 2018, 08:06:23
Danke Andreas!
ich komme mit beiden Vorschlägen zurecht.... favorisiere aber nach wie vor die losgelöste Variante == es gibt nicht für alle Plattformen alle Versionsnummern. Ist in meinen Augen als Anwender logischer - der Entwickler sieht das ggf. anders, klar... |
Title: Re:Losgelöste Builds oder immer für alle Plattformen bauen?
Post by: dg0nf on 26. November 2018, 08:50:00
| Mein Favorit sind losgelöste Versionen (== es gibt nicht für alle Plattformen alle Versionsnummern, erkenntlich wäre das aus der Webtabelle). Nur, wenn sich etwas für die Plattfom geändert hat, gibt es eine neue Version. Tut sich für eine Plattform nichts, wird die UHSDR-Version zwar weitergezählt, aber für einzelne Plattformen gibt es "Löcher" im Versionsschema. |
|
Ich entwickle zwar hier nicht mit, würde aber als Anwender und "Seltenupdater" die obige Lösung auch bevorzugen. Ich weiß gar nicht, was ich aktuell für Versionen auf meinen Geräten habe. Ich nehme eh nicht jede Version mit. So viel Zeit hab ich gar nicht, der dankenswerter Weise schnellen Softwareentwicklung zu folgen. Ich update eigentlich nur, wenn mal was wirklich Neues passiert, oder ich einen Fehler feststelle, der aber meist mit einer neuen Version schon gefixt ist. Ich denke, es genügt, den Anwendern zu sagen/schreiben, dass es neue Versionen für eine Plattform nur dann gibt, wenn sich auch für diese Plattform wirklich etwas geändert hat und dann wird das auch entsprechend angenommen.
Gruß, Helge (DG0NF) |
Title: Re:immer für alle Targets bauen oder nur für die bei denen sich was geändert
Post by: F4HTX on 29. November 2018, 07:24:39
Dear Friends,
After careful reading of the arguments detailed here, it appears to me that there might have a path combining almost both approaches.
Yes, it’s a lot more simpler for the user to see only one version advertised for all platforms, and I would love that.
But we might have to consider that the UHSDR will for sure fork drastically in the future. Because of the policy to support all platforms including very old ones, we will face hardware incompatibility regarding the software (new) features, and we will need to freeze the software for old timers at some point.
The idea might be to keep same version numbering as far as it does the same things, and fork when there is major differences.
For example, I think (correct me if I’m wrong) that the mchf doesn’t run the same noise filtering parameters than the F/H7. In that case a fork seems legitimate.
When it comes to the bootloader 5.01 or 5.02, this is within the same area of features, so I would keep the same numbering.
Not sure that my writing is as clear as my thinking on that…
Best Regards,
François
|
Title: Re:immer für alle Targets bauen oder nur für die bei denen sich was geändert
Post by: DF8OE on 29. November 2018, 09:10:38
Hi François,
forking is a solution which never was on my mind (and isn't yet). The solution must be comfortable for the users AND for the maintainers / development team. Forking would have different code bases and so the work for releasing binaries would increase. So our goal is to keep everything in one code base and swithc different builds via environment variables. which are recognized by MAKE. I am sure there will be forks in the future - but I do not think WE will fork anything...
BTW:
actually filtering is identical on mcHF and OVI40. There is a slight difference in filter coeffs - but the code is exactly the same.
vy 73
Andreas |
Title: Re:immer für alle Targets bauen oder nur für die bei denen sich was geändert
Post by: peter_77 on 29. November 2018, 10:11:55
To my opinion the actual situation fits perfectly well:
- Bootloader version the same for all HW
- Firmware version the same
- "Lite" version for the older HW with limited CPUs
So far its the right procedure and very easy to handle without any confusion.
My 0.02$....
|
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|