Patches als Git-VDR-Fork/Branch auf http://projects.vdr-developer.org pflegen

irgendwie kann man auch alles kaputtdiskutieren.
warum vdr ? es gibt doch kinos

@Mreimer: Niemand spricht hier von einem Fork, können wir das endlich mal ad acta legen ? Es geht hier einzig und allein um Patchverwaltung/Integration/Weiterentwicklung. Ich bin dafür und hoffe das TomG/Tobi/helau/Urig und ein paar mehr eine Meinung zu dem Vorschlag haben. Dabei tut meine und deine Meinung nicht viel zur Sache. Eher die Meinung derjenigen die bisher an soetwas arbeiten/gearbeitet haben.

Moin!

Was ich mir vorstellen könnte:

• im master-Branch ist der vanilla-vdr,
• für jeden Patch gibt es einen eigenen Branch, in dem nur dieser Patch in Bezug auf den vanilla-vdr gepflegt wird
• jemand, der mehrere Patches haben will, legt einen neuen, entsprechend benannten Branch an (z.B. newplugin-defaultsvdrpport-sortrecordings-osdbasemaxitems), in dem die Verträglichkeit der beteiligten Patches gepflegt wird

Das ist aber eine Menge Aufwand und die Anzahl der Branches kann da schnell explodieren (auch die Namen der Branches - evtl. bräuchten wir da sinnvolle Abkürzungen für die Patches).

Ich denke schon, dass zumindest die einzelnen Distributionäre "ihre" Kombination an Patches aber so verwalten könnten. Vielleicht unterscheiden die sich ja gar nicht so sehr und man kann davon profitieren.
Und wenn man die Kombinations-Branches geschickt wählt, indem man z.B. Patches mergt, die überhaupt keinen Konflikt haben, weil sie komplett andere Bereiche des vdr betreffen, hat man sicherlich eine gute Basis, um dann noch "seine" Spezialpatches zu pflegen.

Im Kleinen mache ich es so zu Hause mit meinen Plugins (die Plugins haben jeweils natürlich ihr eigenes Repository). Und mit "git diff master" lassen sich dann so schön Patch-Files erstellen, die dann im "patches"-Verzeichnis des Plugins landen.

Lars.

Zitat

Original von mini73
Ich denke schon, dass zumindest die einzelnen Distributionäre "ihre" Kombination an Patches aber so verwalten könnten.

Da viele Patches die gleichen Bereiche patchen bekämst du dann eine fakultativ große Anzahl von Branches, weil du für viele Patch-Kombinationen einen eigenen Branch bräuchtest.

Das wäre mir etwas zu aufwändig.

Gerald

Moin!

Zitat

Original von gda

Da viele Patches die gleichen Bereiche patchen bekämst du dann eine fakultativ große Anzahl von Branches, weil du für viele Patch-Kombinationen einen eigenen Branch bräuchtest.

Das wäre mir etwas zu aufwändig.

Ja, das ist das Problem. Vielleicht sollte man erst mal daran arbeiten, dass sich die Patches nicht so sehr gegenseitig beeinflussen?
Wenn das überhaupt möglich ist?

Vielleicht wäre ein "Patch-Guide" ein erster Schritt. Wie ändere ich vdr-Dateien so, dass sie sich nicht mit anderen beißen?
Bei den Headern wäre es noch relativ einfach. Am Ende der zu ändernden Klasse fügt man seine neuen und geänderten Dinge hinzu (vielleicht mit Kommentarzeilen inkl. Patchname eingefasst) und löscht sie an der originalen Stelle. Wenn zwei Patche die gleiche Methode anpassen, merkt man das dann sehr schnell.

Aber ich bin nicht sehr erfahren im Verwalten von Patches, da können andere bestimmt bessere Vorschläge machen...

Lars.

Zitat

Original von mini73
Vielleicht sollte man erst mal daran arbeiten, dass sich die Patches nicht so sehr gegenseitig beeinflussen?
Wenn das überhaupt möglich ist?

Das wird kaum möglich sein, da dafür der Patcher die jeweils anderen Patches in diesem Bereich kennen müsste, aber er patcht ja gegen den Vanilla-VDR, was ja auch richtig ist, weil man ein "Normal" braucht.

Zitat

Original von mini73
Vielleicht wäre ein "Patch-Guide" ein erster Schritt. Wie ändere ich vdr-Dateien so, dass sie sich nicht mit anderen beißen?

Wäre sicher eine gute Idee, nur wer hat Lust dazu? Ich jedenfalls nicht.

Gerald

Zitat

Original von mini73
Im Kleinen mache ich es so zu Hause mit meinen Plugins (die Plugins haben jeweils natürlich ihr eigenes Repository). Und mit "git diff master" lassen sich dann so schön Patch-Files erstellen, die dann im "patches"-Verzeichnis des Plugins landen.

Mach' ich hier genau so. Das ist sehr übersichtlich. Ich habe für jeden der Patches einen branch und merge dann all zusammen in einen Branch, den ich dann auf meiner VDR-Kiste installiere und laufen lasse.

Das was sich jetzt herauskristallisiert ist schon nicht mehr ganz so schlecht, wie das am anfang geklungen hat.

Gegen Patches weiterentwickeln hab ich nix. Aber warum soll man das in einem Git machen?

Warum mach ich dann eigentlich den Extensionpatch weiter? Ja ich gebe zu er ist nicht immer perfekt, aber im großen und ganzen klappt doch alles.

Zitat

Warum mach ich dann eigentlich den Extensionpatch weiter?

ist doch auch gut so !
es muss aber auch ohne #ifdef USE_MCLI gehen.
weil ich z.b. nie den setup patch einbauen wollte in unserem paket.
von tomg weiss ich (weil mal angesprochen) das er nie wareagle-icon einbauen würde ... usw. usw.

wenn es trotzdem eine möglichkeit geben würde "alle" patches zu verwalten, ohne das man alle verwenden muss, dann wäre das umso besser.

Zitat

Original von hotzenplotz5
wenn es trotzdem eine möglichkeit geben würde "alle" patches zu verwalten, ohne das man alle verwenden muss, dann wäre das umso besser.

Wenn dir dazu was einfällt wäre ich auch dazu bereit soetwas im Extensionpatch umzusetzen.

naja sinn der sache ist es ja eben nicht "ein" patch für alles.
sondern einzelpatches.
natürlich kann man nicht alles auseinanderpflücken.
d.h. ein patch benötigt einen anderen als "vorraussetzung".
aber ein anfang wäre es.

an werkzeug kenne ich dafür (evtl.) quilt ?!

wie man das dann genau umsetzen kann, oder ob es sich loht, kann ich auch nicht sagen.

ich selber könnte nie was an den patches machen, weil ich besser kathether legen kann als programmieren.

daher müssen wie steffen schon sagte die patchmeister selbst was dazu sagen.
wenn die nicht wollen, lohnt auch die diskussion nicht.

Zitat

Original von Copperhead

Wenn dir dazu was einfällt wäre ich auch dazu bereit soetwas im Extensionpatch umzusetzen.

Dazu ist uns ja was eingefallen, wir benutzen ja deshalb den Multipatch, also im Prinzip die Einzelpatches. Das kommt der hier diskutierten Vorgehensweise noch am nächsten.

Gerald

Es gibt Fälle, in denen Patches sich so stören, dass es mit dem "hintereinanderpatchen" nicht mehr hinhaut. Genau aus diesem Grund wurde ja der Extensionpatch erfunden, da er dieses Problem nicht hat, da ja alles bereits vorgearbeitet ist.

Zitat

Original von Mreimer
Es gibt Fälle, in denen Patches sich so stören, dass es mit dem "hintereinanderpatchen" nicht mehr hinhaut. Genau aus diesem Grund wurde ja der Extensionpatch erfunden, da er dieses Problem nicht hat, da ja alles bereits vorgearbeitet ist.

Wenn es nicht mehr hinhaut, dann haut es auch mit dem Extensionspatch nicht hin. Natürlich musst du die Einzelpatches aufeinander abstimmen und dadurch werden sie voneinander abhängig. Das habe ich auch weiter oben schon gesagt. Ich habe jetzt schon ein paar Jahre VDRs mit beiden Patch-Varianten gepflegt, du auch?

Gerald

Beim ExtP kann man doch auswählen welche Patches man wirklich in den vdr kompilieren möchte. Dann bleibet doch der Originalsourcecode im Kompilat soweit es geht erhalten. Gibt es nicht ein Programm, das einem den Sourcecode je nach gesetzten defines filtert.
Beispiel:

{
#ifdef FOO
   foo;
#endif
#ifdef BAR
   bar;
#endif
}

Und dann

definefilter foobar.c  FOO=1

liefert

{
    foo;
}

oder

definefilter foobar.c  BAR=1

liefert

{
    bar;
}

oder

definefilter foobar.c  FOO=1 BAR=1

liefert

{
    foo;
    bar;
}

Dann bräuchte man nur die entsprechenden Patches aus dem extpatch aktivieren und definefilter über den gepatchten vdr laufen lassen. Am Ende hat man den vdr sourcecode nur mit den benötigten patches. Dies setzt natürlich eine sehr hohe Qualität des ExtP voraus. Damit Copperhead nicht immer die ganze Arbeit alleine machen muss, könnte er den ExtP ja auf project.vdr-developer.de verwalten (falls gewünscht).

LG

Joachim

Ich habe heute wohl zufiele giftige Dämpfe eingeatmet. Definefilter ist natuerlich gerade der c Preprozessor. Mit gcc -E kann man sich wohl die Ausgabe des Preprozessor anschauen, aber dann sind auch alle #include eingesetzt, was man nicht unbedingt möchte.

LG
Joachim

Zitat

Original von gnapheus
Beim ExtP kann man doch auswählen welche Patches man wirklich in den vdr kompilieren möchte. Dann bleibet doch der Originalsourcecode im Kompilat soweit es geht erhalten.

Aber das ist doch gerade der Nachteil von dem Patch. Der ganze tote Kode bläht alles auf und macht es nahezu unlesbar solange du dir nicht alle #defines merken kannst, ich kann es jedenfalls nicht.

Gerald

Zitat

Original von gnapheus
Gibt es nicht ein Programm, das einem den Sourcecode je nach gesetzten defines filtert.

Es gibt unifdef aus dem Paket unifdef, das genau das macht. Ich sehe allerdings darin nur dann einen Sinn, wenn man den Code lesen will, um Fehler aufzuspüren. Dem Compiler ist es egal, ob noch Text vorhanden ist, der nicht mitübersetzt wird.

Das Problem mit dem Ext-Patch ist genau das gleiche wie beim Multipatch und dem Debian-dpatch-Mechanismus, das bei jedem neuen Update des vdr-Basispakets oder bei jedem zwischendurch veröffentlichten Patch von Klaus oder sonst jemanden wieder genau untersucht werden muss, ob die Patches noch passen, ob Anhängigkeiten bestehen und nicht zu Problemen führen und und und...
Ändert man die 00list bei Debian und kommentiert Patches, die man nicht braucht, merkt man da auch schnell Abhängigkeiten.

Getestet ist eigentlich immer nur die Zusammenstellung, die die Distributionsentwickler oder Copperhead beim Ext-Patch wichtig finden.

Ich denke, das wird auch mit git nicht einfacher. Bei 20 nicht integrierten Patches gibt es 20! checkout-Möglichkeiten, wie soll das gehandelt werden? Vielleicht muss doch jeder, der nicht mit der Vorauswahl der Distributionen nicht zufrieden ist, etwas mehr Gehirnschmalz selber reinstecken. Beim Ext gibt es ja immer schnell gute Diskussionen, wenn etwas nicht mehr passt.

evtl. reichen 2 zweige, extpatch + multipatch ?
und der "sinn" des ganzen könnte ein schnellerer blick für andere entwickler sein ?!
oder eben auch zugriff um selber was zu ändern ?
aber vielleicht stell ich mir das zu einfach vor

für mich macht nur ein git-repository mit Einzelpatches gegen den vanilla VDR Sinn. So könnte KLS auch am einfachsten pullen so er denn Lust bekommt. Zur Verwaltung von Patches hat Linus git doch gebaut.

Gerald