Plan: zapit und controld zusammenlegen.

[seife]

Tach.

Ich mal wieder.

Ich würde gerne controld und zapit zusammenlegen.
Grund:
- beide machen teilweise "das selbe" (aus User-Sicht zumindest, bsp: Lautstärke regeln)
- teilweise sagt zapit, je nach Einstellung dem Controld was zu tun ist
- ...und andersrum

Warum die mal getrennt waren, liegt wohl an den besonderheiten der dbox2-Hardware, allerdings limitiert das die Portabilität etwas (auf anderen Plattformen muss man, um den aspect-ratio umzuschalten, nicht das "SAA7126-Deviec" öffnen, das gibts dort nämlich nicht, sondern das "Video-Device", welches allerdings vom zapit und nicht vom controld geöffnet wurde, etc).

Mein Plan wäre:
- controld/ und libcontroldclient/ nach apps/dvb/zapit zu schieben
- dort weiterhin eine libcontroldclient zu bauen aber nur noch ein zapit, keinen controld mehr
- entweder würde diese zapit noch dieselben Schnittstellen anbieten (/tmp/controld.sock und /tmp/zapit.sock) oder die libcontroldclient würde zumindest dieselbe API anbieten (es greift vermutlich niemand ohne libcontroldclient direkt auf controld.sock zu)
- bis jetzt müsste in anderen Codepfaden (neutrino, nhttpd) nichts geändert werden
- dann werden wir die libcontroldclient los (inklusive anpassung von neutrino und Co.)
- später würde dann auch aufgeräumt (ob man noch eine extra controld-Klasse benötigt ist eher fraglich und evtl. würden auch die verschiedenen Sourcefiles etwas aufgeräumt), aber erst mal müsste alles funktionieren.

Hat irgendjemand was dagegen? Der Vorteil wäre, dass neutrino schneller auf neuen Plattformen zum Laufen zu bringen wäre. Der Nachteil, dass auf dem Weg dorthin zwischendurch bestimmt mal was kaputt geht.

Wenn also jemand was dagegen hat, so möge er jetzt reden, oder für immer.... ;-)

[GetAway]

Nur eins, mach bitte nach jedem Patch ne Auflistung von den Sachen
- an denen Du "gefummelt" hast
- was wegfällt, was anders/neu ist
- was auf Funktion getestet werden soll, etc.

Damit könnten wir dann auch schneller Fehlermeldungen posten.

[dwilx]

Na das wär mal was. Ich kann mir aber vorstellen, dass das eine längere Übung werden könnte. Vorschlag: Wäre es nicht sinnvoll hierfür einen Branch anzulegen z.B new_zapitcontrol, wo man das auslagert, dann gäbe das keine Patchorgien und du könntest deine Patches einfach einchecken, ohne dass was am HEAD kaputt geht. Fürs Testen wäre es sicher auch praktischer. Wenn das dann funktioniert, kann man das hinterher einfach übernehmen. Dass man damit umgehen kann, wurde erst neulich mit newmake unter Beweis gestellt. Ich glaube auch, dass das eigentlich der üblichere Weg ist, wozu hat man denn ein CVS.

[Striper]

Bitte so lange bis es läuft und gescheit getestet ist nix ins CVS einchecken, sonst ist dort vielleicht die Hälfte der Zeit ein Sourcecodestand der nicht ordentlich funktioniert.

[seife]

Keine Panik. Die Frage ist, ob generell was dagegen spricht oder nicht. Ich will es ja am Anfang "abwärtskompatibel" halten, so dass erst mal im neutrino etc. nichts geändert werden muss. Das Protokoll wird zwar anders werden (und 2 sockets sind mir zuviel Aufwand), aber das ist durch die libs abstrahiert. Insofern erwarte ich wenig Schwierigkeiten durch die Änderung. Es könnte aber einfach sein, dass ich irgendwas ganz grundlegendes übersehen habe, das _prinzipiell_ dagegen spricht. Oder in meinem Plan ist irgendwo ein Denkfehler, so dass es eben nicht reibungslos laufen _kann_.

Einen extra Branch würde ich gerne vermeiden, das ist mir mit CVS zu umständlich, aber man könnte einen Tag machen, mit der letzten funktionierenden Version ;-)

[dwilx]

Bitte so lange bis es läuft und gescheit getestet ist nix ins CVS einchecken, sonst ist dort vielleicht die Hälfte der Zeit ein Sourcecodestand der nicht ordentlich funktioniert.

Ich glaube du hast das jetzt nicht ganz verstanden, wenn es dafür einen Branch gibt, wäre das ein rein experimenteller Branch, den jeder testen kann um Fehler aufzudecken und zu beheben, solange bis es passt. Erst dann kommts ins HEAD. Für sowas ist ein Branch eigentlich ideal. Meine Meinung...Und solange geht auch nichts kaputt. Was sagen denn die CVS-Experten dazu?

[mohousch]

Die Idee klingt gut, kann hier noch meinen alten Vorschlag wiederholen waere vielleicht auch sehr hilfreich wenn man einen Test-Branch einrichtet oder anders gesagt einen Branch für Seife wo direct der mp2 drinn ist und alle anderen Sachen glaube das sparrt vieles; weas meinen die anderen dazu?!

[Striper]

Einen extra Branch würde ich gerne vermeiden, das ist mir mit CVS zu umständlich, aber man könnte einen Tag machen, mit der letzten funktionierenden Version ;-)

Mit CVS kenne ich mich nicht so sehr aus. Gilt der Tag dann nur für zapit und controld oder wird dann das komplette CVS auf dem Stand eingefroren und man bekommt auch keine Änderungen an anderer Stelle raus beim späteren Auschecken? Wenn dem so ist, halte ich einen Tag für eine schlechte Idee und würde auch einen Branch als sinnvoller erachten.

Bitte so lange bis es läuft und gescheit getestet ist nix ins CVS einchecken, sonst ist dort vielleicht die Hälfte der Zeit ein Sourcecodestand der nicht ordentlich funktioniert.

Ich glaube du hast das jetzt nicht ganz verstanden, ...

Mach dir mal um mich keine Sorgen. Ich hab das schon verstanden. Zudem war mein Post an seife und nicht an dich gerichtet. :wink:

... wo direct der mp2 drinn ist ...

Der mp2 ist doch bereits seit längerem über

Code: Alles auswählen

--enable-movieplayer2

zuschaltbar.

[Barf]

zapit und controld hat zwei ziemlich abgegrenzte Aufgaben: zapit wacht über das DVB-Gerät und AViA-Chip, verwaltet Kanäle, Boquets und solches. controld steuert das Routing von analoges Video und Audio (avsswitch), und die Umwandlung von digitales Video in analoges Video (SAA) (siehe mein Artikel.) Die einzige "Überlappung" besteht dadrin, dass die dBox zwei Formen von Volume kennt, digital (ost) und analog (avs); wobei zapit das ost macht, und controld das avs (mehr detaliert: ost-kommandos werden von controld an zapit weitergeleitet). Das Zusammenlegen ist deswegen am mindestens mir nicht besonderes naheliegend.

controld hat, in Unterschied zu andere *d-Programme, sehr schnell zu erledigende Aufgaben. Eine Alternative wäre wahrscheinlich die controld als C++-Klasse zu behalten, aber ins neutrino-Programm zu verschieben, dabei "controld zu eliminieren".

controld ist ein Stück ziemlich Hitchcock-reifer Code; besonderes ärgerlich ist es, wenn ein Variabel plötzlich seine Bedeutung wechselt!! Hier ist ein etwas aufgeräumte Version von controld.cpp, von der Zeit etwa 2006, wahrscheinlich mit weniger Bugs als die Aktuelle.

Viele von den Probleme die seife anspricht wurde ich so formulieren: Ein HAL (Hardware Abstraction Layer) wäre wünschenswert. (Muss ein Bestandteil von "Newtrino" sein!! ) So sollte man z.B. versuchen, die eklatante Unterschiede zwischen dem Philips-AVS-driver und den Nokia und Sagen-Driver möglist dadrin zu verstecken (und nicht wie die, mMn, gräßliche #ifdef HAVE_DREAMBOX_HARDWARE). scart.conf ist z.B. jetzt auch reif, als Benutzerfummelbare Resource entfernt zu werden.

Zum Branchen: Weil wir in Tuxbox keine Releases haben, ist der HEAD branch (IMHO) etwas "fragiler" als in andere Projekte. Ein experimenteller Branch anzulegen (nicht ein "seife-Branch") ist durchaus zumutbar, und soll nicht mit "zweigleisige Entwicklung" verwechselt werden. Vgl. den io-config-Branch (im Verzeichniss controld). Experimentelle Branches ist eine natürliche Bestandteil der SW-Entwicklung. Die Alternative ist auf Versionsverwaltung zu verzichten bis die Änderung "perfekt" ist...

[rhabarber1848]

Ich halte nicht viel davon, (wieder) einen neuen Branch zu machen, der dann
nicht mit HEAD auf einem Stand ist nur wegen eines Patches, so wie seife
ihn plant. Meiner Meinung nach könnte dieser Patch, wie alle anderen Patches,
über das ULC verteilt und getestet werden, so wie das mit meinen Patches
ebenfalls läuft. Das CVS ist schon unübersichtlich genug...

[mohousch]

das HEAD wie es war/ist ist auch nicht der aller beste Lösung, wie oft sind fehl Commit passiert...,also ich glaube einen stable Branch kann der HEAD auch sein und einen Experimentellen Branch ist gar nicht verkehrt.

[seife]

Tatsache ist, dass die Trennung in controld und zapit _nur_ auf der dbox-Hardware sinnvoll war. Alle anderen Plattformen die ich bisher gesehen habe, haben z.B. kein SAA-Device, und die Sachen die der controld mit dem SAA-Device macht (WSS etc) werden praktisch überall sonst mit dem Video-Device (auf der dbox: AVIA) gemacht. Aus diesem Grund behindert der controld die portierbarkeit ziemlich, was ich letzes Wochenende, als ich mal schnell eine neue Box enablen wollte, schmerzlich gespürt habe.

Da das nun aber in eine CVS-Diskussion ausartet, was ich explizit vermeiden wollte (praktisch die einzige Antwort zur Sache kam von Barf), werde ich das halt hier sein lassen.

[flasher]

Hi

Ich würde das nicht einfach mal so sein lassen nur weil sich mehr Leute um das CVS Sorgen als um den Vorteil der Portierbarkeit.
Persönlich werde ich sicherlich nicht den Rest meines Lebens mit der dbox2 verbringen aber Neutrino hätte ich dann schon gerne und dann möchte ich nicht in "10" Jahren sagen müssen: Schade, kein Neutrino nur weil früher einigen das CVS wichtiger war als die Portiebarkeit.

Gruß

[dbt]

Da das nun aber in eine CVS-Diskussion ausartet, was ich explizit vermeiden wollte (praktisch die einzige Antwort zur Sache kam von Barf), werde ich das halt hier sein lassen.

Von einer CVS-Diskussion würde ich mich nicht beeinflussen lassen, weil das absolut beherrschbar ist und so umständlich auch wieder nicht ist. Da müsste man allerdings die "Schwere" des Eingriffs in betracht ziehen und dann entscheiden wie man das im CVS-unterbringt, denn es macht schon einen Unterschied, ob nur eine kleine Änderung von ein paar Zeilen angewendet werden soll oder eine komplexe Grundlagenfunktion komplett umgestellt wird. In dem Fall würde ich Barfs Meinung zustimmen, dass ein experimeteller Branch geeignet wäre, aber wie gesagt, das kommt drauf an, wie groß der Eingriff werden soll.
Am besten du zeigst einfach, was du konkret für Änderungen hast, denn Portierbarkeit scheint mir doch wichtiger zu sein, als stur weiter an alten dbox2-Relikten festzuhalten, weil absehbar ist, dass das Teil mal in Rente geht. Ausserdem finde ich es äußerst belebend für das Tuxboxprojekt, wenn andere Plattformen einbezogen werden könnten. Wenn sich da nichts tut, wird das sonst auf Dauer irgendwann mal keinen mehr interessieren. Da braucht sich keiner was vorzumachen!

[PauleFoul]

Ich denke Seife bekommt das absolut sauber hin! Wir können ja entsprechend testen...

Immer diese CVS Diskussionen Wäre ja schlimm wenn man mal 2 Wochen nicht den
aktuellen Stand compilieren könnte...

Überlegt mal das Seife einer der wenigen ist die überhaupt noch Sachen einchecken!!

[GetAway]

Schließe mich der Meinung von PauleFoul an.
Wenn's Vorteile bringt und man vielleicht noch 100K dabei spart, dann los.

[doc]

Ich kann die Diskussion um die CVS Eigenheiten auch nicht ganz nachvollziehen.

Was steht denn nun eigentlich im Vordergrund?
Ein Tuxbox CVS was immer kompilierbar sein soll dafür aber sehr geringe Veränderungen am Source bei jedem Checkin oder soll sich die Software an sich weiter voran entwickeln, und da ist das Thema Portierbarkeit ein ganz wichtiges Thema! Letztendlich hat flasher es auf den Punkt gebracht.

Natürlich geht bei so etwas mal was im Source kaputt so das es eventuell nicht mehr jeder direkt gebaut bekommt, aber genau dafür gibt es eigentlich in jedem anderen Softwareprojekt einen stable Zweig der eben immer baufähig sein sollte. Ergo muss man für neue Softwareentwicklungen einen neuen Brunch aufmachen, im Prinzip kann das jeder Entwickler für seine Arbeit machen. Klar das ist natürlich nicht immer sinnvoll bei jedem kleinen Experiment einen eigenen Zweig zu eröffnen.
Aber schaut euch mal an wie viele Zweige es im aktuellen 2.6er Kernel gibt!

Also für mich ist die Sache somit klar.
Head sollte der stabile Zweig sein der von jedem Imagebauer auch benutzbar sein sollte in der Form das man dort immer ein Image/Yadd gebaut bekommt. Für aktuelle Umbauten und Weiterentwicklungen gehört ein experimenteller Zweig ins CVS wo die Devs dann entscheiden on der Zweig dann mit Head gemergt werden kann.

Steht so eigentlich auch in jedem Guide zu RVC ...

Offtopic:
Zum Glück arbeite ich in meinen Projekten mit Subversion und es gibt so Diskussionen nicht.

[MTM]

Hallo,
klitzekleiner Einwurf von mir (als Unwissendem): *Woanders* wird ja offensichtlich daran gearbeitet zapit und neutrino zusammenzulegen, dieses könnte dann ja auch einmal Einzug in die dBox halten. Hätte die Sache hier, mit dem controld, darauf irgendwelche Auswirkungen, ausser daß es halt zwei größere Baustellen gäbe?

MfG,
MTM.

[dwilx]

Ich wollte mit meinem Vorschlag nicht so eine Lavine lostreten, aber man sieht doch wie es in anderen Projekten gemacht wird und da kam mir nur der Gedanke, das anzubringen.
@devs: Und lasst euch himmelswillen nicht davon abbringen herumzuexperimentieren.
Wenn jemand was einbauen will, ist das doch ok. Nur wie ihr das macht, wisst ihr doch sicher am besten, also nix für ungut, macht weiter...

[Houdini]

Tatsache ist, dass die Trennung in controld und zapit _nur_ auf der dbox-Hardware sinnvoll war. Alle anderen Plattformen die ich bisher gesehen habe, haben z.B. kein SAA-Device, und die Sachen die der controld mit dem SAA-Device macht (WSS etc) werden praktisch überall sonst mit dem Video-Device (auf der dbox: AVIA) gemacht. Aus diesem Grund behindert der controld die portierbarkeit ziemlich, was ich letzes Wochenende, als ich mal schnell eine neue Box enablen wollte, schmerzlich gespürt habe.

Macht es Sinn die Befehle an den SAA durch das avia device zu leiten, um damit eine bessere Portabilität zu erreichen?

[rhabarber1848]

das HEAD wie es war/ist ist auch nicht der aller beste Lösung, wie oft sind fehl Commit passiert...,also ich glaube einen stable Branch kann der HEAD auch sein und einen Experimentellen Branch ist gar nicht verkehrt.

Da hast Du schon recht, allerdings befürchte ich, dass die Arbeit von seife in
einem getrennten Branch dort eher versauert, weil kaum jemand das testen
wird. Wenn seife seinen Patch, nach einigem Vorlauf hier im Board, in
HEAD eincheckt, wird er von mehr Leuten getestet und Fehler fallen damit
schneller auf. So geschehen beim rc input-Patch oder den sectionsd-
Umbauten im letzten Sommer. Ich finde, diese Methode hat gut geklappt
und passt zu einem Projekt wie Tuxbox, wo nun nicht wirklich viele Leute
aktiv mitarbeiten. Als Kompromiss wäre es denkbar, vor größeren Umbauten
einen CVS tag (z.B. "before_zapit_controld_merge") einzubauen anstatt eine
eigene branch zu schaffen.

Ein Beispiel dafür, wie Code in den branches versauert, ist driver_2_6_branch.
Am 8.3.2003 wurde die Datei driver/info/tuxbox_hardware_dbox2.c im
besagten Branch erstellt, am 3.12.2005 wurde dieser Patch
in CVS HEAD (Kernel 2.4) eingecheckt, der dafür sorgt, dass beim Yadd-Boot
das Dbox2-Hardwaremodell korrekt aus dem Bootloader ausgelesen werden
kann. Dieser Patch ist nie in die 2.6er-Branch portiert worden und führte zu
Problemen beim Booten, für die nun ein Patch vorliegt. Eines meiner nächsten
Vorhaben ist, den gesamten Code aus driver_2_6_branch schrittweise nach
HEAD zu portieren.

Ich plädiere also für weniger Branches statt mehr. Um einen stabilen
Versionsstand zu markieren, bieten sich CVS tags an, imho.

[Nirvana]

Stimme rhabarber1848 100%ig zu.

[seife]

Macht es Sinn die Befehle an den SAA durch das avia device zu leiten, um damit eine bessere Portabilität zu erreichen?

Ich denke nicht. Dann kommt die nächste Hardware, die das wieder etwas anders macht und dann fängt man wieder damit an.

[ChakaZulu]

das HEAD wie es war/ist ist auch nicht der aller beste Lösung, wie oft sind fehl Commit passiert...,also ich glaube einen stable Branch kann der HEAD auch sein und einen Experimentellen Branch ist gar nicht verkehrt.

Da hast Du schon recht, allerdings befürchte ich, dass die Arbeit von seife in
einem getrennten Branch dort eher versauert, weil kaum jemand das testen
wird. Wenn seife seinen Patch, nach einigem Vorlauf hier im Board, in
HEAD eincheckt, wird er von mehr Leuten getestet und Fehler fallen damit
schneller auf. So geschehen beim rc input-Patch oder den sectionsd-
Umbauten im letzten Sommer. Ich finde, diese Methode hat gut geklappt
und passt zu einem Projekt wie Tuxbox, wo nun nicht wirklich viele Leute
aktiv mitarbeiten. Als Kompromiss wäre es denkbar, vor größeren Umbauten
einen CVS tag (z.B. "before_zapit_controld_merge") einzubauen anstatt eine
eigene branch zu schaffen.

Ein Beispiel dafür, wie Code in den branches versauert, ist driver_2_6_branch.
Am 8.3.2003 wurde die Datei driver/info/tuxbox_hardware_dbox2.c im
besagten Branch erstellt, am 3.12.2005 wurde dieser Patch
in CVS HEAD (Kernel 2.4) eingecheckt, der dafür sorgt, dass beim Yadd-Boot
das Dbox2-Hardwaremodell korrekt aus dem Bootloader ausgelesen werden
kann. Dieser Patch ist nie in die 2.6er-Branch portiert worden und führte zu
Problemen beim Booten, für die nun ein Patch vorliegt. Eines meiner nächsten
Vorhaben ist, den gesamten Code aus driver_2_6_branch schrittweise nach
HEAD zu portieren.

Ich plädiere also für weniger Branches statt mehr. Um einen stabilen
Versionsstand zu markieren, bieten sich CVS tags an, imho.

Sorry für OT

Ich finde, dass Code eher versauert, wenn er in irgendeinem Thread als Patch gepostet wird. So oder so muss sich jemand darum kümmern, ob als Patch oder branch. Wobei es natürlich auch auf die Art/den Umfang der Änderung ankommt, aber gerade so was wie driver_2_6 würde ich nicht als
Patch verwalten, da man längere Zeit daran arbeitet und mit ausschließlicher Arbeit mit Patches auch gleich komplett auf eine Versionsverwaltung verzichten könnte (der Branch liegt sozusagen auf dem privaten Rechner des (einzigen) Entwicklers, der Code im CVS-branch immerhin im Repository).

Das eigentliche Problem ist aber m.M. nach - wie Du auch schon andeutest - dass man keine Releases oder
stabilen Stände taggt oder brancht sondern davon ausgeht, dass HEAD *jederzeit* als Basis für ein voll funktionstüchtiges Image genommen werden kann. Für mich ist HEAD der Entwicklungsbranch, wo eben die Weiterentwicklung stattfindet und auch nicht funktionsfähige Codeteile enthalten sein können (compilieren sollten sie aber schon...). Das würde aber zumindest ein rudimentäres Releasemanagement usw. erfordern, was niemand machen wird (wobei das ja wiederum implizit gemacht wird, wenn man Patches erst nach umfangreichen Tests ins CVS bringt).

Ein weiteres Problem ist sicher auch, dass viele Leute nur bestimmte Patches anwenden/testen/rückgängig machen wollen und aus deren Sicht das Patchmanagement so einfacher ist bzw. Effekte anderer Änderungen ausgeschlossen werden können.

Aber wenn eh nur Seife dran arbeitet, dann ist es seine Entscheidung

ciao,

ChakaZulu

[rhabarber1848]

Ich finde, dass Code eher versauert, wenn er in irgendeinem Thread als Patch gepostet wird.

Dafür gibt es diesen Thread