Das finde ich genau richtig so. Ist ein separater Entwicklungsbranch, und der hat noch keine Versionsnummer oder Tag (mehr s.u.).
War nur ein Gedanke, in der osdteletext.c steht nämlich dazu: *VERSION = "2.1.0.beta.2";. Liegt wohl an der Strategie die sich mir auch noch nicht so ganz erschließt 
Natürlich steht die Weiterentwicklung an erster Stelle, dafür ebenfalls ein Danke von mir 
Kurzer Einwurf von mir, ohne mich einmischen zu wollen :p Und es ist auch keine Kritik, sondern eine Frage
Wenn schon alles auf github liegt, warum arbeitet ihr nicht mit nur 1 master branch, brancht den und stellt dann einen pull request auf den master, den andere reviewen können, testen können, man dann selber nachbessern und danach mergen kann.
So wird es zum Beispiel bei mesa gemacht, was ich als ganz angenehme Arbeitsweise finde.
Das Problem ist immer, wenn
a) es nur ein oder wenige Entwickler für ein Projekt gibt
b) schnelle Pushs erfolgen sollen.
Eine gute Arbeitsweise wäre natürlich immer, das 4-Augen-Prinzip anzuwenden. Das kann man mit der oben dargestellten Form machen in dem man beim pull request auf ein <Reviewed-by> wartet...
Man kann natürlich alles überbürokratisieren, aber so bekommt man auch eine gewisse Codequalität sichergestellt und vermeidet reverts...
EDIT: Oh, sehe grade, es gibt ja pull request, nur keine "fremden" reviewer
Gruß
Andreas
PS: Hab das plugin jetzt übrigens auch drauf. Ist es "normal", dass die alte Seite "ausblendet", wenn eine neue aufgerufen wird? Oder soll osdteletext "hart" zur neuen Seite übergehen?
Ich noch 3-4 Varianten der alten Seite im Hintergrund mit steigender Transparenz, bis sie dann weg ist. Kann aber auch ein Problem meines Ausgabeplugins sein.
EDIT: Oh, sehe grade, es gibt ja pull request, nur keine "fremden" reviewer
damit fangen die Probleme an...alles in Personalunion...und aktuell kann der Weg holprig sein, das Ziel ist mir wichtiger...(und es könnte wesentlich schlimmer sein...alles in meinem Fork, kein Branch daran, Fork-master-runs-as-it-is...oder auch nicht, und zum Schluß keine Möglichkeit mehr, das mit cherry-pick zusammenzuklauben und dann bleibt nur noch all-or-nothing.
Den "milestone-2.1.0" Branch habe ich deswegen angelegt, damit andere nicht dauernd das Repo umschalten müssen für Beta-Tests...da gab's auch Gemecker...
Und im Upstream-Master haben die Änderungen noch nichts zu suchen, bis 2.1.0 fertig ist, wer weiß, ggf. muß noch 2.0.x gefixt werden...ok, man könnte da einen release-maintenance-Branch erstellen und ggf. cherry-pick machen (falls der Commit kleinteilig genug war...was ich eh schon versuche so ganz nebenbei...wenn auch mit Grenzen, zuviele Abhängigkeiten/Baustellen gleichzeitig)
PS: Hab das plugin jetzt übrigens auch drauf. Ist es "normal", dass die alte Seite "ausblendet", wenn eine neue aufgerufen wird? Oder soll osdteletext "hart" zur neuen Seite übergehen?
Ich noch 3-4 Varianten der alten Seite im Hintergrund mit steigender Transparenz, bis sie dann weg ist. Kann aber auch ein Problem meines Ausgabeplugins sein.
Also es wird ein OSD erzeugt und darin die Seiten final mit osd->DrawBitmap reingepinselt - da ist nichts mit Aus- und Einblenden hinterlegt. Noch nicht mal beim Kanalwechsel während Teletext-OSD aktiv ist, wird ein neues OSD erzeugt, hier mit softhddevice (und auch eHD) ist alles fix.
Selbst der ClearPage (das aber nur noch beim Kanalwechsel aufgerufen wird), malt nur Leerzeichen mit transparenten Vordergrund und schwarzem Hintergrund.
Hat die OSD-Implemetierung im Ausgabeplugin irgendeine seltsame Fading-Option? Verkleinere das OSD mal auf 80% und schalte den schwarzen Rahmen an und prüfe ob Du da im Rahmen auch Artefakte siehst bei Umschalten - weil der wird nur am Anfang pro OSD gemalt.
Und OSDs werden nur bei Größenänderungen neu gemacht, sind auch im Log erwähnt, z.B.
osdteletext: OSD area successful requested with x0=68 y0=59 width=1320 height=800 bpp=32 lF=59 rF=59 tF=59 bF=59Im VDR-Umfeld muss man wirklich um jeden froh sein der wichtige Plugins weiterentwickelt. An der Stelle danke pbrb für die Arbeit!
Aber wenn ich einen Tipp abgeben darf: Ich glaube den meisten würde es schon was bringen wenn du einfach im "offiziellen" Repo für neue Features Branches anlegst. Von einem Branch auf's "master" sollte ein Pull-Request möglich sein. Dann gibt es abgesplittete Branches wo neue Features getestet werden und "master" für den aktuellen Stand.
"offiziellen" Repo für neue Features Branches anlegst
das habe ich ja nun gemacht und füttere den mit PRs, die mindestens meine Dev-"QA" passiert haben...
https://github.com/vdr-project…text/tree/milestone-2.1.0
sollte jetzt fertig sein...eben die letzte Unschönheit bei den ChannelSwitch-Meldungen rausgebaut. Wie schon erwähnt, Videotext vom Nachbar-Kanal auf dem selben Transponder kann man auch bei 1-Tuner-System nun "live" mitlesen.
Hallo Zusammen,
auch von meiner Seite erstmal Danke für die Weiterentwicklung des Teletext Moduls ... ich nutze es immer noch sehr gerne, weil man noch schneller Kurzinfos bekommt als z.B. in der Tagesschau-App ...
Zur Nutzung von git ... wir nutzen bei uns dafür git flow:
https://nvie.com/posts/a-successful-git-branching-model/
https://danielkummer.github.io…eatsheet/index.de_DE.html
Da kann man wirklich einfach Feature-, Release-, Hotfix-, ... Branches mit erstellen und verwalten und auch das Mergen (inkl. Tagging) geschieht dann teilweise automatisch.
Schöne Grüße, Space
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
