[ANNOUNCE] VDR Git Tree

tadi · 10. September 2008

Bedingt durch Diskussionen auf der VDR Mailingliste haben wir uns entschlossen einen Git Tree der VDR Quellen zu erstellen und öffentlich zugänglich zu machen:

http://git.gekrumbel.de/?p=vdr.git

WICHTIG: Dies soll keine Abspaltung der VDR Entwicklung sein.

Bitte lest weiter um zu Verstehen was mit dem Git Tree des VDR gemeint ist:

Git ist ein verteiltes SCM (source code management) System. Jedes Git Verzeichnis (engl. git tree) enthält dabei die Historie des Projektes und die Historie welche der Besitzer des Trees hinzugefügt hat.

Der hier vorgestellte Git Tree ist für alle read only. Nur Michi (skiller2k1) und ich (tadi) werden den Tree mit dem Code von Klaus aktualisieren. Nur Code den Klaus veröffentlicht wird in den Tree aufgenommen. Damit stellt dieser Git Tree eine Historie der offiziellen VDR Entwicklung dar. Andere Änderungen wird es darin nicht geben.

Andere Entwickler profitieren von unserer Arbeit, indem sie sich diesen Git Tree clonen, Erweiterungen einbringen und ihre Arbeit in eigenen Git Trees veröffentlichen können. Dabei sollten sie immer sehr deutlich machen wodurch sich die abweichenden Trees vom Orignal unterscheiden. Wenn Klaus neuen Code veröffentlicht, können diese Änderungen über den 'original Quellen Tree' (von uns) durch einen 'pull' eingepflegt werden.

Wir wollen eine Liste von geclonten und veränderten Trees pflegen und auf einer Webseite veröffentlichen. Daher wünschen wir darüber informiert zu werden, wenn jemand einen modifizierten Git Tree veröffentlicht. Möglicherweise wird jemand dann aus diesen Trees einen gemeinsamen Tree mit allen Modifikationen kombinieren und veröffentlichen.

Wir sind überzeugt davon, dass dieser Ansatz Klaus die Freiheit lässt den VDR so weiter zu entwickeln wie er es für die Funktionalität und Stabilität seines Codes erforderlich hält.

Durch die gemeinschaftliche Arbeit, die durch Git gut unterstützt wird, können andere Entwickler ihre Erweiterungen der VDR Community bereit stellen. Dadurch soll das mühselige Suchen nach Patches vereinfacht werden und die vorhandenen Änderungen auffindbar gemacht werden. Im Grunde ist dieser Vorschlag ein Ansatz die vielen unterschiedlichen Patches besser zu verwalten.

Lasst uns gemeinsam auf dieses Ziel hin arbeiten.

Grüße
Dieter

PeterD · 10. September 2008

Find ich gut.
Hoffe Klaus auch, er hatte sich bisher immer dagegen ausgesprochen.
Mache mittlerweise praktisch kaum noch was an code ohne ein SCM im hintergrund.

Es wäre schön tatsächlich die wichtigen patches als seperate trees zu pflegen.
Wäre schön wenn dann mal häufiger gute patches in den haupttree übernommen würden.
Aber was ist mit den megapatches, ala bigpatch

Was ist mit plugins ?
Einige kernplugins hätten auch ein SCM verdient.
(also wieviel platz habt ihr zur verfügung )

Peter

kls · 10. September 2008

Zitat

Originally posted by PeterD
Find ich gut.
Hoffe Klaus auch, er hatte sich bisher immer dagegen ausgesprochen.

Mir würde es nur nicht gefallen, wenn es ein SCM gäbe, in das jeder eichecken kann und ich müsste dem dann immer "hinterherrennen" bevor ich eine neue Version rausbringen kann.

In der Form wie hier finde ich das aber ganz gut.

Klaus

PeterD · 10. September 2008

Zitat

Original von kls
Mir würde es nur nicht gefallen, wenn es ein SCM gäbe, in das jeder eichecken kann und ich müsste dem dann immer "hinterherrennen" bevor ich eine neue Version rausbringen kann.

In der Form wie hier finde ich das aber ganz gut.

Klaus

Na ja, beim kernel darf das auch nicht "jeder".
Ich denke aber es gibt mittlerweise einen harten kern von VDR entwicklern in der mailingliste die sicher dann einige teile übernemen könnten und Dir sicher einige "integrationsarbeit" abnehmen könnten.

gruss Peter

free-x · 10. September 2008

kls

es ist nicht sinn und zweck, dass jeder in tree commiten darf. Du bekommst deine Tree, die du nach Lust und Laune weiterführst. Allerdings du kannst Mergen mit anderen, was schon handhabung von patches vereinfacht. Und das zweite ganz wichig: community weiss in welche richtung die Reise geht und wird nicht reagieren mit patches für plugins mit neuer API, sondern es wird rechtzeitig da. Und drittes es werden die Duskussionen wie z.B. über PES->TS viel früher stattfinden und man kann die vereiteln überhaupt.

Am Ende möchte ich nur Eric S. Raymond aus dem "Die Kathedrale und der Basar" zitieren

Zitat

7. Früh freigeben. Oft freigeben. Seinen Anwendern zuhören.

P.S. Danke Leute für dieses Historisches Museum

PeterD · 10. September 2008

Zitat

Original von free-x
... drittes es werden die Duskussionen wie z.B. über PES->TS viel früher stattfinden und man kann die vereiteln überhaupt.

Genau, jede diskussion muss bereits im keim erstickt werden ...

Freud'scher versprecher oder hoffentlich doch eher verteiler ...

cjhbabel · 10. September 2008

Also den VDR über git zu bekommen finde ich auch gut. Vor allem kann man damit erstmal selber seine eigenen Änderungen/Erweiterungen testen und bei Bedarf dann vorstellen. Und für die echten Experten wird es einfacher 2-3 Trees bei Bedarf zu mergen.

free-x · 10. September 2008

vieleicht hab ich falsch ausgedruckt ( Deutsch ist nicht meine Muttersprache).

Aber als Beispiel können wir die letzte Diskussion ansehen: [ANNOUNCE] VDR developer version 1.7.1
Also beim Umstellung von PES->TS ist plötzlich pvr350 nicht in der Lage zusammenzuarbeiten. Was wäre wenn das früher bekannt wurde und UFO hätte auf richtige StreamID in PES hingewiesen.
Und sowas passiert nicht einmal. Die Geschichte von VDR ist reich an solchen Beispielen. Diskussion über CHARSET_OVERRIDE auch sehr interessant.
Oder diskussion über doppelte SID auf einem Satellit. Klaus meint, dass das nicht DVB konform sei. Leider in Praxis sieht das ganz anders aus. Aber das hat nicht mehr GIT Tree zu tun. Also

tadi · 10. September 2008

Hallo

Es freut mich zu hören, dass Klaus das in dieser Form auch ganz gut findet.
Unsere Idee ist genau die, dass nicht jeder in ein zentrales SCM einchecken darf. Und das ist auch nicht der Workflow den Git empfiehlt.

Die Idee hinter Git ist Dezentralität. D.h. jeder der etwas beitragen will setzt sich ein eigenes Veröffentlichungsgit auf. Darin befinden sich nur die jeweiligen eigenen Änderungen. Wenn jemand Änderungen von A und von B benötigt, dann führt er diese Änderungen in seinen eigenen Git Tree zusammen indem er von A's und B's Git Tree pulled. Das darf er dann gerne wieder veröffentlichen, aber das macht er dann unter seinem Namen.

Das hier dargestellte Bild zeigt ein wenig wie ich mir das vorstelle. Die genannten Git Trees (außer dem von uns angekündigten) gibt es zum jetzigen Zeitpunkt noch nicht. Es wäre schön, wenn die genannten Personen diesen Ansatz aufgreifen, erzwingen kann ich es jedoch nicht.

[Blockierte Grafik: http://git.gekrumbel.de/img/git_tree_hierarchy.png]

Ob jetzt nur ein Patch pro Tree oder mehrere das muss sich erst empirisch herausstellen. Denkbar wäre, dass es in einem Tree mehrere 'single' Patch Branches gibt und eine 'alle Patches' Branch. Alternativ kann eine Person auch mehrere Trees bereit stellen.

Ein Hosting von Git Trees haben wir nicht vor. Dazu gibt es genügend freie und kommerzielle Git Hoster im Internet (z.B. repo.or.cz, Gitorius etc. Auf der Git Homepage werden noch weitere gelistet). Ein Git auf einem eignen evtl. vorhandenen Server bereit zu stellen (wie wir es gemacht haben) ist auch nicht so aufwändig. Bei Nachfragen sind wir zu Hilfe bereit.

Wir wollen jedoch eine Übersichtsseite mit veränderten Git Trees pflegen. Dazu benötigen wir jedoch die entsprechenden Ankündigungen und Veröffentlichungen. Noch haben wir keine, deswegen existiert diese Seite noch nicht.

Grüße
Dieter

PeterD · 10. September 2008

Zitat

Original von tadi
Das hier dargestellte Bild zeigt ein wenig wie ich mir das vorstelle. Die genannten Git Trees (außer dem von uns angekündigten) gibt es zum jetzigen Zeitpunkt noch nicht. Es wäre schön, wenn die genannten Personen diesen Ansatz aufgreifen, erzwingen kann ich es jedoch nicht.

Perfekt würde das wenn ihr Klaus direkt von GIT überzeugen könnt.
Dann könntet ihr euch sogar den import sparen.

free-x

Nicht böse sein aber der "verschreiber" war schon lustig

Das "vereiteln" sollte wohl "verteilen" heissen, nur bedeutet "vereiteln" eben "verhindern", nur falls du den wortwitz nicht genau verstanden hast.

tadi · 10. September 2008

Zitat

Original von PeterD

Perfekt würde das wenn ihr Klaus direkt von GIT überzeugen könnt.
Dann könntet ihr euch sogar den import sparen.

Alles der Reihe nach. Erst muss sich unsere Idee erstmal etablieren. Was Klaus dann später macht - sollte es funktionieren - kann und soll er dann selber entscheiden. Klar wäre es von Vorteil, wenn der Basis Git Tree direkt von Klaus stammt. Aber das muss jetzt noch nicht sein.

Leiste lieber zunächst Überzeugungsarbeit bei den VDR Patch Entwicklern um diese Idee zum laufen zu bekommen.

Grüße
Dieter

kls · 10. September 2008

Zitat

Originally posted by tadi
Klar wäre es von Vorteil, wenn der Basis Git Tree direkt von Klaus stammt.

Ob ich ein komplettes TAR-Archiv veröffentliche und ihr das unverändert in euer GIT einlest, oder ich das selber reinschreibe, macht letztendlich ja wohl keinen Unterschied

Also kann jeder, der will, einfach meine Archive ignorieren und warten, bis der jeweilige Stand im GIT ist...

Klaus

Urig · 13. September 2008

Zitat

Originally posted by tadi
Das hier dargestellte Bild zeigt ein wenig wie ich mir das vorstelle. Die genannten Git Trees (außer dem von uns angekündigten) gibt es zum jetzigen Zeitpunkt noch nicht. Es wäre schön, wenn die genannten Personen diesen Ansatz aufgreifen, erzwingen kann ich es jedoch nicht.

Nicht böse sein, aber ich bleibe erst mal beim Veröffentlichen von Patches.

Falls aber jemand meine Patches in einem Repository weiter veröffentlichen will, habe ich nichts dagegen. Nur zu!

Gruß,

Udo

PS: Ich lagere schon seit Jahren alle VDR-Versionen in mein privates SVN ein. So ein Blick in die Entwicklungsgeschichte ist manchmal einfach sehr hilfreich...

[ANNOUNCE] VDR Git Tree

Jetzt mitmachen!

Teilen