[osdteletext] 2.0.0 released

  • früher war's anders implementiert:


    void cPluginTeletextosd::initTexts()


    aber damit nicht außerhalb von osdteletext.c zugreifbar, dachte ich damals zumindest...ich werd das mal wieder zurückbauen und so zu erweitern, daß da alle Texte aufbereitet (tr...) werden und auch zugreifbar vom Rest.

  • früher war's anders implementiert:


    void cPluginTeletextosd::initTexts()


    aber damit nicht außerhalb von osdteletext.c zugreifbar, dachte ich damals zumindest...ich werd das mal wieder zurückbauen und so zu erweitern, daß da alle Texte aufbereitet (tr...) werden und auch zugreifbar vom Rest.

    Zurückgebaut, bitte testen:


    https://github.com/pbiering/vd…ext/tree/2.0.2-regression


    "Treppenwitz" der Fortentwicklung...inzwischen werden die Texte außerhalb vom Plugin-Setup gar nicht mehr gebraucht...weil es nun speziell auf 10 Zeichen angepaßte in einem extra Array gibt....

  • https://github.com/pbiering/vd…ext/tree/2.0.2-regression

    -> leider noch kein Feedback bekommen


    https://github.com/pbiering/vd…t/tree/2.1.0-second-tuner

    -> nun im Beta-Stadium, selbst wer nur einen Tuner hat, kann damit nun Teletext "live" ("tuned" mode) lesen von einem Sender auf dem selben Transponder, z.B. "tagesschau 24" <-> "ARD-alpha"

  • https://github.com/pbiering/vd…ext/tree/2.0.2-regression

    -> leider noch kein Feedback bekommen

    Gestern, bei einem kurzen Test, gab es keine Probleme, im Setup ist alles übersetzt. Danke!

  • Gestern, bei einem kurzen Test, gab es keine Probleme, im Setup ist alles übersetzt. Danke!

    Danke für's Feedback, Release erstellt:


    https://github.com/vdr-project…etext/releases/tag/v2.0.2


    Jetzt kann ich in Ruhe mal 2.1.0 weiter finalisieren...mal schauen, wann erstes Feedback mich erreicht...paar kosmetische Verschönerungen sind auch schon drin...die Message-Box wird zweizeilig, wenn der Sendername drin steht.

  • Release erstellt

    Die beiden GIT Stände sind aber nicht per Commit auf den Stand 2.0.2.


    Hab gerade beide GIT Stände gebaut vom Plugin aber keinen Tag....

    Gruß utiltiy



    VDR Projekte VDR Projects

  • -> leider noch kein Feedback bekommen

    Wenn man potentiellen Testern erzählt, dass sie das falsche Repository benutzen, und sie mit einer chaotischen Branch-and-Merge-Strategie (ok, vielleicht habe nur _ich_ das System nicht verstanden) ohne Tags alleine laesst, dann laeuft es eben darauf hinaus.

    Und ansonsten, Feedback innerhalb von 11 Stunden wuerde ich jetzt ohne spezielle Absprache nicht unbedingt voraussetzen.


    Release erstellt

    Releases v2.0.1 und v2.0.2 sind identisch, was vermutlich nicht so gedacht ist.

    Auch sind im master immer noch die tr() statt trNOOP() fuer st_modes drin. Auch das erscheint mir nicht sinnvoll.


    Und nein, _dieses_ Release v2.0.2 funktioniert immer noch nicht, meldet sich ja auch 2.0.1.


    Gruss,

    S:oren

  • Sorry, hab vor dem Release den PR vergessen....jetzt paßt es, 2.0.2 hat jetzt auch drin, was drin sein sollte.

  • Wenn man potentiellen Testern erzählt, dass sie das falsche Repository benutzen, und sie mit einer chaotischen Branch-and-Merge-Strategie (ok, vielleicht habe nur _ich_ das System nicht verstanden) ohne Tags alleine laesst, dann laeuft es eben darauf hinaus.

    ansich ist "per-Entwickler-Fork-Repo" schon eine gute Idee, mit Hilfe von PRs laufen dann verschiedene Änderungen von N Entwickler im Hauptrepo zusammen, wo sie von N Maintainer rein Review bekommen und reingemergt werden. Hauptrepo bekommt dann von Zeit zu Zeit auch Releases.

    Aktuell ist aber N==1 und M==1 und auch noch identisch...Bewerbungen als Reviewer werden gerne angenommen.


    Alphatester könnten Ihr lokales Repo auf multi-upstream erweitern (git remote add ...) und dann jeweils umschalten von Entwickler zu Entwickler-Fork und darin auf Branches, die die Basis von einem PR bilden.


    Betatester könnten sich dann auf Hauptrepo fokussieren, falls es PRs (und die sollten ggf. schon mal einen Alphatest von einem 2. bekommen haben) bis dahin geschafft haben.


    Issue-Tracking auf Github wäre auch besser als hier im Forum, weil dann wären die PRs gleich verlinkt...

  • Es gibt ja genug Plugins wo man aus einem Repo sowohl die Tags und die Commits raus bauen kann, wie man will. Bei diesem Plugin hier ist halt das "gewurschtel" zwischen den beiden "Adressen" sehr groß wie bereits beschrieben ;)

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Ein Entwickler-Repo halte ich auch fuer eine sehr gute Idee. Auch gerne mit verschiedenen aktiven Entwicklungs-/Topic-/Test-/Was-auch immer-Branches (neben dem master).


    Bitte einen Branch fuer jede Entwicklungslinie, diese Branches immer basierend auf einem getaggten Release, und nur an einer Sache gearbeitet in jedem Branch. Bei auftretenden Problemen gerne mit auch mal mit einem topic-v2-Branch (basierend auf dem selben Tag wie topic), wo mit git rebase (fixup/squash) die Probleme in den Commits des topic(-v1)-Branches gefixt werden und so spaeter noch die wirklich letztendlich sinnvolle Entwicklung nachvollzogen werden kann. Die Commits gerne mit einer sinnvollen Beschreibung, _warum_ man etwas so gemacht hat (was geht ja aus dem Code hervor). Beim Beschreiben merkt meist man selbst recht schnell, ob das so eigentlich wirklich Sinn ergibt.


    Wenn dann ein Feature fertig und getestet ist, dann wird das in in den master gemerged (nicht umgekehrt). Ich bin ja eher ein Freund von rebase, wenn sowieso nur ein Entwickler daran arbeitet. Aber auch jeweils ein expliziter Merge-Commit waere ein sinnvolle Strategie, was dann fuer Einheitlichkeit bei Merges von externen Topic-Branches aus Repositories anderer Entwickler sorgt. Dann koennen anschliessend die lokalen topic(-vx)-Branches wieder geloescht werden.


    Nach einem oder mehreren Topic-Merges wird dann _im master_ eine neue Version erzeugt und getaggt. Und dieser getaggte master-Branch aus dem Entwickler-Repo wird dann unveraendert in das Haupt-Repo gepusht (nicht gemerged), so dass die git-IDs in beiden Repos fuer Releases identisch sind.



    Das halte ich fuer eine sinnvolle git-Entwicklungsstrategie, kann es hier natuerlich nur so vorschlagen. Sicherlich ist das auch nicht die einzig moegliche Strategie, z.B. git-flow sieht noch kompliziertere Regeln vor. Das halte ich hier fuer uebertrieben, ist nur meine persoenliche Meinung.


    Letztendlich braucht man auch nicht unbedingt ein zweites Entwickler-Repo, wenn man direkt im Haupt-Repo arbeitet (und sich daran haelt, dort niemals im master zu entwickeln). Dann braucht man auch kein lokales Repo mit mehreren Remotes (was an sich kein Problem waere, ich habe z.B. auch ein lokales Repo mit 4 Remotes). Hier fuer osdteletext funktioniert das nur nicht (gut), weil eben die Releases im Entwicklungs- und Haupt-Repo nicht die selben Commit-IDs haben.


    Mal so als Anregung,

    S:oren

  • Richtige Handhabung von git ist wohl nicht so trivial...und meine Kenntnisse darin nicht die besten....ich gebe gerne die Leitung vom Haupt-Repo wieder ab und liefere dann nur über PRs ein, die dann ein *zweiter* begutachtet und mergt oder sonstwie zusammenführt und von Zeit zu Zeit Releases macht, nachdem *dritte* (QA) den Master im Haupt-Repo für releasewürdig befunden haben.


    Alpha-/Beta-Tester können weiterhin in Forks nach latest-greatest-ggf-buggy-Branches oder Master suchen und vorher schon ausprobieren...


    Ich werde mal mit Milestone-Branches anfangen und die PRs dagegen laufen lassen...dürfte sauberer sein.

  • So, mein 2.1.0 branch ist nun im offiziellen "milestone-2.1.0" Branch reinmigriert:


    https://github.com/vdr-project…text/tree/milestone-2.1.0


    - ChannelSwitch now supports receiving other channels from same transponder or even other transponder (aka "tuned" mode)


    (und bei boxed - aka "Untertitel" wird die 1. Zeie dauerhaft angezeigt...damit man nicht total verwirrt ist, wenn man die Untertitel vom Kanal 1 sieht während man Kanal 2 im Live-TV hat...)


    Der kann jetzt ausgiebig getestet werden...

  • So, mein 2.1.0 branch ist nun im offiziellen "milestone-2.1.0" Branch reinmigriert

    Naja, meldet sich wieder mit 2.0.2_38_gb2f5e02 als Version weil kein Tag vorhanden ist. Nach welcher Grundlage werden die großen Sprünge in kurzer Zeit der jeweiligen Versionen hier eigentlich geändert?


    Soweit weg kannst Du ja nicht sein, von einer Funktionsweise im Umgang mit dem GIT damit das Pushen und Taggen passt. Wenn es wo klemmt wird dir sicher hier geholfen und eine Frage ist ebenfalls kein Beinbruch ;)


    Du müsstest auch nicht die Version als "beta" umschreiben, es reicht doch zu jedem Tag (also neues Release) die Version anzupassen. Die Stände dazwischen sind "Entwicklungsstände", das machen doch alle anderen auch so. In der obigen Zeile wäre es dann der 38igste Commit nach dem Release 2.0.2

    Gruß utiltiy



    VDR Projekte VDR Projects

    The post was edited 1 time, last by utiltiy ().

  • Sprung auf 2.0.0: VTX -> VTX5 und X/26-Support -> massive Erweiterung


    2.1.0 -> multi-tuner-Support


    der milestone-2.1.0 hat noch kein Tag, weil noch nicht fertig, ist in meinen Augen ein Beta-Branch, wird wohl noch paar Regressionen abgekommen werden...da PR nicht das Tag verschieben müßte jemand nach einem PR wieder ein neues anlegen...und später wieder löschen, weil unnütz.


    ...wenn das immer noch nicht gefällt, dann mach ich nur noch PRs und um das Hauptrepo und die Einsortierung kund Taggen ann sich jemand anders kümmern...


    Vielleicht versteh ich auch git immer noch zuwenig...mein Hauptaugenmerk liegt auf Verstehen und Fixen und Erweitern vom Code und zurückbringen ins Haupt-Repo, weil ich will nicht im privaten Fork den aktuellen latest-greatest-release drin haben. Den Fork-Zoo von anderen, wo latest-best 3 Forks tiefer sich aktuell "versteckt" und niemand sich ums Zurückmergen in den (ehemaligen) Master kümmert find ich ziemlich komisch...wenn da mal jemand sein privates Git zusperrt, kann man mühsam das Einsammeln von anderen Clones anfangen und im worstcase tgz wieder ins Git zurückspielen...ein Community-Projekt sollte besser zentral bleiben.

  • Wenn man das Repo von markad mal nimmt als Beispiel, da ist der Master Zweig und wenn erweitert wird der Zweig V02 der wo entwickelt wird, wenn es passt kommt es nach Master rüber gemerged.

    Hat jetzt nichts mit Zoo oder so zu tun, ist schlicht, einfach, funktionell. Kann auch sein dass du es nicht so machen willst sondern einen eigenen Weg hast, dann eben diesen ;)

    Gruß utiltiy



    VDR Projekte VDR Projects

  • Naja, meldet sich wieder mit 2.0.2_38_gb2f5e02 als Version weil kein Tag vorhanden ist.

    Das finde ich genau richtig so. Ist ein separater Entwicklungsbranch, und der hat noch keine Versionsnummer oder Tag (mehr s.u.).


    ...wenn das immer noch nicht gefällt, dann mach ich nur noch PRs und um das Hauptrepo und die Einsortierung kund Taggen ann sich jemand anders kümmern...

    Du bist Maintainer, kannst also machen, was Du willst.

    Ich hatte beschrieben, wie ich es handhaben wuerde, wenn ich Maintainer waere. Diese Regeln sind natuerlich nicht die einzig sinnvollen, haben sich aber in anderen großen Community-Projekten (linux, u-boot) bewaehrt. Ob man sich hier darauf einigen moechte, wurde ja noch nicht mal diskutiert.


    Das Einhalten solcher Regeln erfordert Disziplin, ermoeglicht aber auch eine einfachere Zusammenarbeit und ergibt eine bessere Qualitaet und Wartbarkeit des Codes. Der Branch milestone-2.1.0 erfuellt wieder quasi alle meine Regeln nicht (muss er auch nicht, ich bin ja nicht der Maintainer). Aber so weiss ich weder, was ich testen sollte (welche Features/Fixes,...), noch kann ich irgendwas reviewen (was ist der Grund fuer die Aenderungen, gibt es bessere Implementierungsalternativen), noch ist klar, in welcher Beziehung dieser Branch zum aktuellen master steht, und was der aktuelle Stand (Version/Tag) sein soll.


    mein Hauptaugenmerk liegt auf Verstehen und Fixen und Erweitern vom Code

    Gerne in dieser Reihenfolge. Besser als vorhandene Features erst aus- und dann wieder einzubauen, oder anerkannte Standardloesungen ignorieren, weil es manchmal trotzdem auch anders funktioniert.


    Nun ja, vieles ist Geschmacksache. Es gibt sicher verschiedene Ansichten. Etwas Toleranz von allen Seiten ist fuer ein Freizeitprojekt sicher auch nicht verkehrt.


    Unbestritten duerfte sein, dass Du das Plugin weiterentwickelt und neue Features eingebaut hast, was sicher nicht nur fuer mich einen bedeutenden und gern gesehen Fortschritt darstellt. Danke dafuer.


    Wie hier eine (weitere) Zusammenarbeit im Sinne eines Community-Projektes aussehen soll, verstehe ich allerdings leider noch nicht. Deine "chaotische Branch-and-Merge-Strategie", wie ich es genannt habe, ist so komplett anders als alles, was ich kenne, dass ich nicht weiss, wie ich damit umgehen soll. Anscheinend geht es anderen Leuten auch so. Und dieses Plugin sollte doch allgemein nutzbar bleiben, waere schade sonst.


    Gruss,

    S:oren