[patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

den branch vdpau-extensions-patch-xine-lib-patch" gibt es nur damit nicht jeder die patches von der xine mailing liste runterladen muss und von hand "einbauen". Wer die Patches selber einbauen will kann dies nat. immer noch selbst in den durchflieger branches tun. Sollte die Patches ins xine-lib hg einfliessen , wird der Branch wieder entfernt und man hat wieder eine besser Übersicht bei den Branches

Zitat

Original von sparkie
helau  fnu
also sorry:
Wenn jemand im Beispiel wie 'durchflieger' schon ueberhaupt Zeit investiert, um seine Entwicklungen, die er zunaechst nur fuer den Privatgebrauch taetigt oeffentlich zu machen, dann ist das schon ehrenwert genug.

Es geht nicht um Durchfliegers Branches, die sind auch gut dokumentiert,
sondern um Branches die kommen und gehen.
Mag sein dass ich da zu altmodisch bin, aber ich wuerde nie auf die Idee kommen, wegen ein paar Patches fuer ein paar Wochen ein komplettes git aufzuziehen, ich halte dies fuer ne Resourcenverschwendung.

P.S:

Zitat

In den wenigsten Faellen hat man dann als Entwickler noch Zeit, den Distributoren alles mundgerecht zu praesentieren.

Darueber koennen wir gerne mal ernsthaft diskutieren, wenn Du mal soviel Software entwickelt hast, wie ich in 25 Berufsjahren als Programmierer

Jungs, jungs, das ließt sich hier ja wie im Tuxbox Portal, da gab es auch die Diskussion Git versus mercurical und wie sie sich sonst noch so nennen. Über Tage und Wochen und mit dem Ergebniss, dass einige so verprellt waren, dass sie nicht mehr öffentlich weiter gemacht haben

Da ich nichts davon verstehe, sollte ich vielleicht besser mich raus halten, aber wie auch im normalen Job geht vieles leichter und es erspart allen Parteien Arbeit wenn es eine gemeinsame Kommunikation gibt und Infos in beide Richtungen verständlich und nachvollziehbar sind.
Es bringt sonst nichts etwas zu entwickeln, wo es nicht richtig oder schlimmsten Fall gar nicht entdeckt wird, genauso wie auch in die andere Richtung detaillierte Fehlermeldungen wünschenswert sind.

Ich weiß auch, dass es eine Untugend ist im privaten gerne mal fünfe gerade sein zu lassen (sprich Dokumentation), wo im Job der Teamleiter einem die Nase lang ziehen würde.
Selbst aus Anwendersicht weiß ich trotz täglicher Anwesenheit nicht immer was die ganze Flut von Änderungen an den Paketen letzten Endes bewirken. Auch dies macht mir die Fehlereingrenzung schwer, da zu vieles gleichzeitig verändert wird.
Was nicht bedeuten soll, dass ich was gegen den aktuellen Entwicklungsdrang habe! Was sich in den letzten Wochen getan hat ist mehr als im ganzen letzten Jahr. Und das aktuelle Ergebnis ist nahe dran hervorragend fast perfekt zu sein.

Gibt es denn einen gemeinsamen Nenner wo jeder was von hat? Wenn nicht, können wir uns die Zeit sparen darüber zu reden, es würde zu nichts führen.

Gruß
Torsten

Hallo,

durchflieger: verstanden.

Für mich war Entwickler und derjenige der die branche baut immer jemand anders.
Somit habe ich gedacht, Du schreibst code, rnissl schreibt code und ein andere baut und pflegt die branches.

Wenn natürlich jeder Entwickler sein eigenes branche hat, bin ich bei Helmut und finde das Verschwendung.

Nichts für ungut, ich kann auch gut damit leben.

Viele Grüße
kaminkehrer

Zitat

Originally posted by helau
Mag sein dass ich da zu altmodisch bin, aber ich wuerde nie auf die Idee kommen, wegen ein paar Patches fuer ein paar Wochen ein komplettes git aufzuziehen, ich halte dies fuer ne Resourcenverschwendung.

Es ist mit git auf jeden Fall einfacher, schneller und bequemer als das Hantieren mit separaten Patches.

Zitat

Original von that
Es ist mit git auf jeden Fall einfacher, schneller und bequemer als das Hantieren mit separaten Patches.

Das "schneller" halte ich fuer ein Geruecht Arbeite mal mit Dorf-DSL, da bist Du froh wenn Du moeglichst wenig downloaden musst.
P.S: Von mir aus koennt Ihr auch gerne weiterhin git repositories basteln, aber dann lasst diese wenigstens auch ne Weile stehen, oder schreibt dort wo diese repos mal waren einen Vermerk dazu warum es diese nicht mehr gibt

Hi,

leider muss ich eingestehen, an der Problematik eine gewisse Mitschuld zu haben, da ich bisher eine commit-Berechtigung im xine-lib Repository abgelehnt habe. Der Weg der Patches über die Mailingliste ist für mich am einfachsten und sollte dazu führen, dass sich die entsprechenden Commiter das nochmals ansehen, bevor es offiziell wird. Leider bindet dieses Vorgehen auch Resourcen der Commiter, und wenn die gerade keine Zeit haben, dann geistert über längere Zeit ein ganzer Schwung Patches rum.

Die commit-Berechtigung habe ich auch abgelehnt, da ich mich zur Zeit mit mercurial (wie auch mit cvs, svn, git, ...) nicht genügend auskenne, um ein Repository richtig zu führen. Und xine-lib ist mir dafür als Spielwiese zu heikel.

Aktuell bin ich noch der Meinung, dass ich die wenige Zeit, die mir für dieses Hobby bleibt, besser ins Codieren stecke.

Bye.

Zitat

Original von kaminkehrer
Wenn natürlich jeder Entwickler sein eigenes branche hat, bin ich bei Helmut und finde das Verschwendung.

Was soll denn das heißen? Mir als Entwickler erleichtern diese verschiedenen Branches enorm die Arbeit. Jetzt soll ich darauf verzichten, weil du es für Verschwendung hältst und andere verwirrt?

Gerald

Ich finde die verschiedenen Branches auch super, würde mir sogar noch ein weiteres zum Testen wünschen (mit allen Patches drin).

So kann jeder frei entscheiden welche Änderung für Ihn am Besten ist.
Und man ist auch nicht gezwungen jedes Patch-Level mitzumachen.

Marco

Hi,

Was ich mich frage, aus welchen Quellen soll man eigentlich xine-ui bauen?

Peter

hallo,

Zitat

Original von pixelpeter
Was ich mich frage, aus welchen Quellen soll man eigentlich xine-ui bauen?

ist seit einiger zeit nun in einem mercurial - ich nehme immer den letzten stand:

hg clone http://hg.debian.org/hg/xine-lib/xine-ui/

gruß, ciax

...was mich mal interessieren würde:
Besteht die Möglichkeit den ehemaligen Streamstart-Patch abgewandelt wieder (vielleicht dauerhaft) einzuarbeiten? Die Grab- und Spulgeschichte nervt mich persönlich nicht so sehr wie das Pixeln beim Umschalten! Es mögen ja viele Verbesserungen in den letzten Wochen eingeflossen sein, aber die r11592 mit den Patches, DF-20 und gepatchtem xine ist doch noch mein persönlicher Favorit (persönlich!) und ich schwenke immer wieder zurück.

gda,

Zitat

Was soll denn das heißen? Mir als Entwickler erleichtern diese verschiedenen Branches enorm die Arbeit. Jetzt soll ich darauf verzichten, weil du es für Verschwendung hältst und andere verwirrt?

Auf keine Fall, bitte nicht falsch verstehen.

Wie oben geschrieben habe ich gedacht Coder und Organisator waren unterschiedliche rollen. Ich habe gedacht (schon schei...) das das git zusätzliche Aufwand bedeutet.

Wenn es so ist wie Du und durchflieger sagen, dass das git dem coder beim organisieren seines eigenen codes hilft, dann soll er es auf jeden Fall tun.

Da ich viel zu wenig Ahnung vom coden und der Organisation so großer Programme habe, halte ich meinen da lieber raus.

Somit vergesst bitte was ich dazu geschrieben habe.

Macht bitte so weiter wie Ihr euch am besten organisieren könnt ich bin für die Ergebnisse sehr dankbar.

Viele Grüße
kaminkehrer

Hallo,

zum eigentlichen Thema:

Nach meinem Verständnis hat rnissel Verbesserungen im OSD und spulen mit xineliboutput mit seinen patchen eingebaut.

Die letzten durchflieger Änderungen optimieren das graben des streams und OSD.

Für mich ist jetzt nicht klar ob beide Änderungen am OSD zusammen passen oder ob es Grundsätzlich eine andere Vorgehensweise ist um das "Problem" zu lösen.

Um nun das zur Zeit Optimale xine-lib zu haben, müssten die letzte durchflieger Version mit den patchen von rnissel zum spulen nehmen oder die letzte rnissel Version mit den code Änderungen für das '"grabben" von durchflieger? Oder alles von rnissel mit allem von durchflieger, passen dann die OSD Anteile zusammen?

Für mich als nur Nutzer und Profitierer der Mühen anderer, ist es wohl am besten ich warte bis eine kumulierte neue Version online gestellt wird.

Viele Grüße
kaminkehrer

hallo,

Zitat

Original von kaminkehrer
[..]rnissel Verbesserungen im OSD und spulen mit xineliboutput mit seinen patchen eingebaut.
[..]

ich glaube eher, daß er das mit seinem vdr-xine plugin getestet hat

gruß, ciax

ps: ganz allgemein waren ja die meisten patches in erster linie für die xine-lib

Hallo,

wenn ich einmal ganz kurz die Diskussion unterbrechen darf...

Ich habe den neuen xineliboutput-df-xine-lib-extensions.patch.gz Patch von durchflieger gestern Abend getestet und bin mit dem Resultat sehr zufrieden. Das grabben der Bilder und die Aufbereitung für den DF10CH Atmolight Controller funktionieren bei mir mit dem xv output driver sehr gut.

Ein dickes Lob an durchflieger und herzlichen Dank.

Gruß
Jürgen

Zitat

Originally posted by mgoeben
Ich finde die verschiedenen Branches auch super, würde mir sogar noch ein weiteres zum Testen wünschen (mit allen Patches drin).

So einen Branch kann man sich ja dank git sehr einfach selbst erzeugen, so habe ich das gestern gemacht, nur um zu sehen ob es wirklich einfach ist:

git clone git://projects.vdr-developer.org/xine-lib.git    (Vorsicht Dorf-DSL-User :), ~200 MB Download)
cd xine-lib
git merge origin/xine-lib-extensions
git merge origin/vdpau-extensions-patch-xine-lib-patch

Derzeit gibt es da keine Konflikte beim Merge dieser Branches, also ist sonst nichts mehr zu tun.