Umfrage zu Patches starten?

Hallo,

einige Patches (z.B. der, bei dem man das bevorzugte Video-Verzeichnis wählen kann, oder JumpPlay, oder LiveBuffer) sind sicher kaum sinnvoll als Plugin zu realisieren.

Dennoch kommen die meisten Distris mit einem der Patch-Pakete mit >40 Patches(!). Nachteile habe ich daraus bisher nicht ausmachen können.
Die meisten Patches 'vertragen' sich ja (sonst wären sie ja nicht in einem Multi-Patch).

Ich bin kein Software-Entwickler (auch wenn ich mehr oder weniger programmieren kann), aber ich kann mir nicht vorstellen, dass -sobald einmal integriert- es großer zusatzaufwand ist, wenn die Patches upstream integriert sind.

Gruß,
Hendrik

Wurde nicht genau aus diesem Grund ein git-Repository eingerichtet in das die patches rein sollen?

klaus kann gemütlich vor sich hin entwickeln - wenn was neues kommt wird das gegen das git gepatcht und schon gibts eine gepatchte neue Version...

Zusatzaufwand wird das entwickeln bei jeder Zeile!

Alleine wenn man das ganze testen muss wenn man irgendwo in den Internals was ändert.

Zitat

Original von oe6jwf
Wurde nicht genau aus diesem Grund ein git-Repository eingerichtet in das die patches rein sollen?

Ein Workaround...

Zitat

klaus kann gemütlich vor sich hin entwickeln - wenn was neues kommt wird das gegen das git gepatcht und schon gibts eine gepatchte neue Version...

Vorausgesetzt es gibt keine Rejects.

Zitat

Zusatzaufwand wird das entwickeln bei jeder Zeile!

Alleine wenn man das ganze testen muss wenn man irgendwo in den Internals was ändert.

Ach so, und das ist im obigen Fall besser?

Natrürlich muss man beim Entwickeln die Änderungen beachten.
Aber Zusatzaufwand bei jeder Zeile? Nehmen wir Jumpplay: Da wird es kaum Interaktion mit anderen Entwicklungen geben. Dito für Vidprefer. Die meisten Patches betreffen doch genau eine Funktion.

Im Gegenteil: Wenn die Patches *nicht* upstream enthalten wird, dann *kann* Klaus nicht darauf acht geben, dass sie weiterhin funktionieren.

Gruß,
Hendrik

Naja Linus hat auch einen Haufen nicht drinnen, was der Hr. Morton schon lange verwendet...

Ich halte in meinen Repos in der Firma auch möglichst nur Funktionalität die ich auch tatsächlich verwende... Es kommt immer wieder vor, dass ich einen bösen Anruf bekomme weil irgendwas, das ich irgendwo, irgendwannmal gedreht hatte (aus mehr oder weniger logischen gründen) dann auf einmal Seiteneffekte wirft... Nur weil etwas kompiliert, heißt das noch lange nicht, das es auch funktioniert wie es soll... Und alles was ich nicht dauernd verwende, wird irgendwann einmal ungetestet bleiben. Das sind dann aber zu 99% dann die Dinge, die ich für irgendwen anders eingebaut habe.

Beim VDR habe ich z.B bis auf diese patches für epgsearch (Menü-Ersetzen-Dings) keinen einzigen Patch drinnen... Bin trotzdem sehr glücklich und mir geht auch nichts ab... Das liegt aber auch daran, dass ich die Zeit nicht finde Patches durchzuprobieren... Und das ist wieder der Punkt! Würde ich jetzt bei meinen 4 VDRs überall alle Patches am laufen haben (und das hätte ich, weil die sich automatich aus meinem Repository updaten), dann würde es sicher nicht lange dauern bis Bruderherz irgendwo eine Funktion gefunden hätte, die gerade nicht so tut wie sie immer getan hat.

Was ich damit sagen will ist, es wäre durchaus sinnvoll mehrere Repositories zu pflegen. Zu sagen, ich mach eine Umfrage, damit der Sourcen-Geber gefälligst "irgendwelche Patches" reinmacht und darauf achtet, dass die auch in Zukunft noch funktionieren ist irgendwie gewöhnungsbedürftig...

Ich für meinen Teil werde mir das mit den XBMC-Patches noch genauer anschauen... Immerhin will ich das in meine Distri reinbringen... Dann gibts ein XBMC-VDR-Repository wenn das schon soweit funktioniert wie ich mir das erhoffe.

Das es sicher auch keine schlechte Idee wäre gewisse Patches im Hauptzweig aufzunehmen ist auch klar!

Aber wenn man sich diesen Thread (wie auch die Vorgänger) so durchliest, liest sich das Ganze irgendwie so: "Klaus mach uns die Patches rein, weil wir zu faul sind sie anzuwenden und zu pflegen!"

73

Zitat

Original von oe6jwf
Aber wenn man sich diesen Thread (wie auch die Vorgänger) so durchliest, liest sich das Ganze irgendwie so: "Klaus mach uns die Patches rein, weil wir zu faul sind sie anzuwenden und zu pflegen!"

73

Wenn dem so wäre, würde sich der VDR nie weiterentwickeln, weil man nur mit dem "verpatchen" beschäftigt wäre. Irgendwann hat meine eine trilliarde patches und diverse Plugins, die Abhängigkeiten darauf besitzen funktionieren nicht. Auch blöd oder?

Wir können doch froh sein, dass der VDR so extrem "Communitydriven" ist und man auf die Programmierfreudigkeit vieler Nutzer hier zurückgreifen kann, um zum Beispiel auch die Performance zu verbessern (zum Beispiel Text2Skin-Patch von chr13, auch wenns nix mit dem VDR selbst zu tun hat.)

Zitat

Original von methodus

Sehe ich auch so. Es gibt zwei Möglichkeiten, die Unzahl der Patches zu beseitigen:
Variante 1: So viel wie möglich in den VDR einpflegen mit der Gefahr, dass der Code unsauber werden könnte und neue Patches notwendig sind

Variante 2: Schnittstellen schaffen, und die Pluginentwickler selbst die Probleme beseitigen auch wieder mit der Gefahr, dass Plugins, die verwaist sind, gar nicht mehr gehen.

Da ich kein Pluginentwickler bin, wenige Plugins und daher kaum Patches benutze, nur meine bescheidene Meinung:
Geht zuerst mit der zweiten Variante ran. Bildet eine "Schnittstellentaskforce" die ermittelt wie die Schnittstellen in Zukunft aussehen müßten, damit kaum noch Plugins am vdr rumdoktorn müssen, um zu funktionieren. Die Schnittstellen müßten recht mächtig sein, gleichzeitig aber soweit im Hintergrund bleiben können, das vdr wie vorher funktioniert, das "Innenleben" sich nicht ändert, wenn sie nicht benutzt werden. Damit kann sie auch Klaus leichter warten, da er nicht wissen muß welches Plugin diese Schnittstelle benutzt, er muß wenn notwendig nur wissen was diese Schnittstelle an Ein/Ausgaben erwartet.
Der Rest an Patches sind dann die, die in das "Innenleben" eingreifen, die muß man dann gesondert überprüfen.

Zitat

Original von oe6jwf
Das es sicher auch keine schlechte Idee wäre gewisse Patches im Hauptzweig aufzunehmen ist auch klar!

MAINMENUHOOKS verwende ich z.B selber, da epgsearch erst damit richtig spaß macht... würde mir also auch nix ausmachen wenn ich das nicht patchen müsste

Wenn man sich so die Changelogs vom VDR anschaut scheinen da genügend Leute patches eingereicht zu haben.

zulu dein Vorhaben ist schon OK... möglicherweise reagiere ich bei Threads mit diesem Thema immer etwas übertrieben... Das liegt aber oft an der Tatsache, dass es irgendwann von "klaus könnte dann abwägen ob und welchen er reinnimt" zu "klaus weiß dann welchen er reinnehmen soll" geht.

Wie schon angemerkt haben die diversen distri-leute ja allerhand patches dabei... es wäre also meineserachtens für alle beteiligten sinnvoll einen vdr-wieauchimmer brach anzulegen.
Das ganze könnte man als Community-Testing-Zweig sehen.

Damit können alle VDR Entwickler ungestört arbeiten und die Patch-Schreiber hätten ihre Patches "upstream". Für Leute die gerne Vanilla VDRs haben, gibts die offiziellen Source, die "ich brauche jedes Feature" Menschen haben auch ein Repository und die Distri-Leute dürften sich auch einiges an Arbeit ersparen.

Ausserdem hat sich damit das Gepatche und über rejects-Ärgern für viele erledigt.

Gibts mal wieder einen neuen Major-Release ist die Übernahme von Änderungen aus dem "Testing"-Zweig sicher überlegenswert. Da sehe ich sowas wie Zulu gerade macht als gute Idee an.

Das Irgendwer das Ganze warten muss ist mir vollkommen klar!

Naja das sind zumindest meine Gedanken zu dem Thema.

Hallo,

ich lasse mich gerne eines Besseren belehren, aber ist es nicht so, dass es weniger Aufwand* ist, einen Patch zu integrieren und dann mit diesem den VDR weiterzuentwickeln, als für jede Version des VDR eine neue Version des Patches erstellen zu müssen?

Davon abgesehen:
Gibt es bei anderen OS-Programmen die gleichen Patch-Kulturen?

Gruß,
Hendrik

* hier geht es nicht um die Frage 'für wen', sondern in Summe.

http://www.kernel.org/patchtypes/mm.html
http://www.kernel.org/pub/linu…2.6.28-rc2-mm1/patch-list

ist auch nicht wenig...
1856 files changed, 187350 insertions(+), 65556 deletions(-)

Und jede Distri pflegt nochmal ihre eigenen Repositories... sogar Slackware schiebt hin und wieder non-vanilla Kernels raus...

Außerdem habe ich bereits mehrmals geschrieben, dass ich ja prinzipiell für die Aufnahme von Patches bin. Es wäre nur sicher sinnvoller zuerst alle in einem eigenen VDR-branch zu haben und dann bei Major-Releases Patches in den Hauptzweig zu mergen.

Es gäbe dann insgesamt eine breitere Anwenderschar die alle Patches testet... so haben die einen keine, andere wieder bigpatch und vllt wieder andere den extension-patch... ich würde das einfach einmal zusammenfassen und schaun was passiert anstatt sie mit aller Gewalt sofort in den Hauptzweig zu pressen.

Aber gut. Jeder darf seine Ansichten haben.

73

Zitat

Originally posted by zulu
Was ist denn 'Toni' für ein Patch oder fangen jetzt die ersten an unsere schöne Umfrage zu sabotieren?

[englisch]I'd guess, some Finn (it's a finnish male name) without enough German knowledge did add his name into patch submit field. It really would nice, if the survey was in english as someone already requested on the mailing list.
The survey contains plenty of plugins now (osdteletext, streamdev, epgsearch, femon, live, ..). These should be removed from the database and disable the user option to add new "patches".[/englisch]

Some plugins require patches to the VDR to be working, thats why these are listed in there.

Die Umfrage ist jetzt auch auf englisch.

Welche Einträge sollen denn konkret gelöscht werden?

Zitat

Originally posted by steffen_b
Some plugins require patches to the VDR to be working, thats why these are listed in there.

But for my knowledge those plugins doesn't require any patches (femon, osdteletext, epgsearch, sc, streamdev, live, toni :), ...) and then there are plugins that do require patches, but the patches are listed twice: for example IPTV and PLUGINPARAM patches are exactly the same. I strongly suggest do a cleanup and some kind of patch validation or the whole survey gets messed up...

Zitat

Original von rofafor
.... and then there are plugins that do require patches, but the patches are listed twice: for example IPTV and PLUGINPARAM patches are exactly the same.

i also noticed that..

Zitat

'PLUGINPARAM' und 'IPTV' meint den gleichen Patch. Bitte Ergebnisse zusammenfassen.

Would be very useful to have at least this one already inside unpatched vdr, since prvinput (and other input devices..) could use that one too.

zulu
Vorallem tauchen immer mehr Plugins in der Umfrage auf welche auch ohne Patches gut funktionieren.

Vielleicht sollte man die Patches genauer dokumentieren, ich vermute das viele - mich eingeschlossen - dank zulu diverse Patches verwenden welchem einem das Leben erleichtern aber gar nicht wissen welcher Patch für welche Funktion zuständig ist.

Die Kurzbeschreibung in der Umfrage ist hier nicht immer hilfreich, dies war für mich auch der Grund nur mir bekannte Patches überhaupt zu bewerten.
Auch habe ich nur Patches berücksichtig die ich als unbedingt nötig empfinde, ansonsten könnte man ja auch gleich sagen alle Patches müssen in den plain VDR einfliesen.

Auch müsste eine Unterscheidung der Patches vorgenommen werden ob diese nur optische oder funktionelle Erweiterungsmöglichkeiten bieten.

Von mehreren Test VDR Zweigen halte ich nicht viel, wenn ich nur sehe wie schwer es ist die eHD im vdr-1.6.0 bzw. 1.7.x zum laufen zu bekommen weil Reel in seinem 1.4.7er einen anderen Weg beschritten hat.