So. Ich bin ziemlich durch mit den Plugins. Ist so ziemlich alles gemirrored.
Außerdem habe ich mir mal die Zeit genommen eine kleine Webseite hochzuziehen, mit einer groben Erklärung.
https://vdr-projects.github.io
Is noch nicht perfekt. Aber es ist ein Anfang.
mini73: Ich habe dir mal die Einladung geschickt. Wenn du sie annimmst bist du ebenfalls Organization Owner.
Jupp, danke! Bin gespannt, ob es wieder ein wenig Schwung gibt.
Lars
Hoffentlich wird github helfen, die Verbreitung des VDRs zu steigern.
Ich hätte eine Frage: Kann man das erste Repo (vdr-projects.github.io) nicht irgendwie nach "VDR Projects README" umbennen? Wenn ich nicht vorher über diesen Thread auf die englische Seite mit den Erläuterungen gegangen wäre, hätte ich nicht gewusst, dass es das README ist.
Außerdem, würde ich vorschlagen einen "Sticky Thread" über das neue github in der NEWS und in der International Sektion dieses Forums anzulegen.
Ich hätte eine Frage: Kann man das erste Repo (vdr-projects.github.io) nicht irgendwie nach "VDR Projects README" umbennen? Wenn ich nicht vorher über diesen Thread auf die englische Seite mit den Erläuterungen gegangen wäre, hätte ich nicht gewusst, dass es das README ist.
Leider nein. Github legt wert auf den Repositorynamen. Ich habe aber eine Readme.md angelegt, die innerhalb des Repositories darauf hinweist, dass es das Repository für die Webseite ist.
Außerdem, würde ich vorschlagen einen "Sticky Thread" über das neue github in der NEWS und in der International Sektion dieses Forums anzulegen.
Das ist geplant. mini73 meinte er wäre die nächsten zwei Wochen schwer zu erreichen. Entweder ich warte, bis er wieder besser erreichbar ist, oder ich schreibe selber etwas zusammen. Mal sehen.
Im Moment bin ich mit dem Projekt schon weiter als ich erwartet habe.
Ich hoffe auch immernoch an die Original RCS Daten des VDRs zu kommen. Das bekomme ich sicherlich irgendwie nach Git transferiert. In gewisser Weise ist es unnötig, aber ich bin ehrlich gesagt super neugierig auf einzelne Commits und damit auch tiefere Einblicke in die Entwicklung zukünftiger VDR Versionen.
kls hat sich hier nicht mehr wirklich geäußert, eventuell schreibe ich ihn da auch nochmal direkt an.
Auch geplant ist es, das Mirroring für ältere Plugins wieder abzuschalten und stattdessen das Github Repo als neuen Hauptzweig zu betrachten. Dann entsprechend die Patches zusammentragen.
Immernoch einiges zu tun...
Ich hoffe auch immernoch an die Original RCS Daten des VDRs zu kommen. Das bekomme ich sicherlich irgendwie nach Git transferiert.
Die original RCS-Dateien möchte ich ungern rausgeben. Wenn, dann geht es nur so, daß ich daraus per Script ein GIT-Archiv generiere und das auf meinen Server hochlade.
Zitat
In gewisser Weise ist es unnötig
Zitat
aber ich bin ehrlich gesagt super neugierig auf einzelne Commits und damit auch tiefere Einblicke in die Entwicklung zukünftiger VDR Versionen.
Das würde mich jetzt aber doch interessieren, wie man aus vergangenen Änderungen Vorhersagen für künftige Versionen machen kann ;-).
Klaus
Die original RCS-Dateien möchte ich ungern rausgeben. Wenn, dann geht es nur so, daß ich daraus per Script ein GIT-Archiv generiere und das auf meinen Server hochlade.
RCS ist so unglaublich veraltet, dass es da noch kein Skript gibt. Das müsste erst geschrieben werden.
Alles was ich finde konnte zielt darauf ab, dass man zu Git konvertiert und danach RCS nicht weiterbenutzt und auch das setzen schon auf die Ähnlichkeit zu CVS.
Wenn alle Stricke reißen müsste ich mich in RCS einlesen und ein Dummy-Repository aufbauen. Dann bräuchte ich aber ein paar Infos von dir, wie du z.B. Commits kennzeichnest, die über mehrere Dateien gehen.
RCS kann scheinbar nur Commits pro Datei und ist noch "Atomic commit"-fähig. Solltest du da aber eine einheitliche Konvention haben, z.B. sind die Commitmessages gleich, oder ähnliches könnte man daraus die passenden Commits generieren.
Das würde mich jetzt aber doch interessieren, wie man aus vergangenen Änderungen Vorhersagen für künftige Versionen machen kann ;-).
Naja. Meine Hoffnung war es, dass dadurch auch Commits von zukünftigen noch nicht veröffentlichten Versionen sichtbar werden. Sozusagen "bleeding edge"
Edit: Habe mir RCS mal genauer angeschaut. Damit arbeitest du? Wirklich? Kommt mir sehr umständlich vor.
Damals gab es nichts anderes,damit haben wir alle mal angefangen... 
Lars
Damit arbeitest du? Wirklich? Kommt mir sehr umständlich vor.
Finde ich nicht - es macht genau, was es soll ;-).
Klaus
Die ganze Sache würde eigentlich nur Sinn machen, wenn man mehr oder weniger das gesamte RCS-Repository öffentlich duplizieren würde. Bei einem öffentlichen RCS wäre das zwar für die Masse wenig hilfreich, würde aber zumindest in der Theorie ein moderiertes Übertragen in ein GIT erlauben bei dem dann auch die Commit-Messages und Versions-Tags stimmen.
Ein GIT, das zwar "Nightlies" trägt, aber keine sauberen Commit-Messages, halte ich für wenig hilfreich.
Eventuell wäre es da nach aktuellem Stand schon hilfreicher wenn man so ein GIT tatsächlich in die neue "vdr-projects" Organisation baut und dann halt releases und Patches einsammelt. Aufwändig aber dank Issue-Tracker schaffbar, denn wenn irgenwo ein Patch von Klaus gepostet wird, könnte der erste, der den findet, ja einfach ein Issue oder Pull-Request machen.
Im Prinzip bräuchte man dann für jede VDR-Stable einen Branch um die Versionsgeschichte sauber zu halten.
Zumindest mein Gedanke war halt, dass es schöner wäre, wenn Klaus bei Fixes nach einem Release statt einen Patch irgendwo ins Forum oder die Mailingliste zu werfen, einfach in sein Repo commited und ins öffentliche Repo pusht. So eine Art von Funktionalität geht mit jedem VCS "besser" als RCS. Sogar CVS könnte man dafür verwenden. Wobei CVS halt, anders als GIT, nicht viel kann ohne den Server.
Nicht jeder Patch, den ich poste, landet auch zwangsläufig in der nächsten Version. Da wird auch gerne mal was ausprobiert, das dann wieder verworfen oder anders realisiert wird. Das möchte ich nicht alles im RCS "verewigt" haben.
Ich würde mich jetzt ganz gerne wieder auf die eigentliche Entwicklung konzentrieren...
Klaus
Das VDR-Wiki halte ich VDR4Arch technisch schon länger nicht mehr auf dem neuesten Stand. Der aktuelle Wiki Artikel ist hier: https://github.com/VDR4Arch/vdr4arch/wiki
Und ans Arch Wiki selbst habe ich mich noch nicht rangetraut. Irgendwie habe ich da Respekt vor. Irgendwer hat da auch schon einen Link zu VDR4Arch reingemogelt.
Da wird auch gerne mal was ausprobiert, das dann wieder verworfen oder anders realisiert wird. Das möchte ich nicht alles im RCS "verewigt" haben.
Das geht in Git aber auch wunderbar, solange man nicht einen Stand committed passiert nichts, wenn man mal etwas "falsches" commited hat kann man das auch wieder entfernen/beheben/ändern. Rein von der Funktionalität kann Git mindestens alles das was RCS auch kann.
Ob man sich in "aktuelle" standard Techniken einarbeiten will steht da natürlich auf einem anderen Blatt (fun fact, RCS wird in einer Git Repo entwickelt)
Ich hoffe auch immernoch an die Original RCS Daten des VDRs zu kommen. Das bekomme ich sicherlich irgendwie nach Git transferiert.
Warum nicht RCS -> CVS -> Git ? Das ist zwar extrem bekloppt aber sollte gehen, es gibt RCS -> CVS importer und CVS -> Git klappt ja auch.
Die ganze Doku für RCS -> CVS ist zwar richtig alt aber das sollte ja trotzdem noch gehen auch wenn heute schon CVS veraltet ist. Das sollte sich ja auch automatisieren lassen.
*Rant*
Besser wäre natürlich eine offizielle Quelle in einem nicht gnadenlos veraltetem VCS System damit man mit aktuellen Standard Tools darauf zugreifen kann. Also im Endeffekt das was jede Open Source Software als Gold Standard bietet.
Aus meiner Perspektive nicht sonderlich erbaulich das sowas 2017 überhaupt noch "diskutiert" werden muss.
Das geht in Git aber auch wunderbar, solange man nicht einen Stand committed passiert nichts, wenn man mal etwas "falsches" commited hat kann man das auch wieder entfernen/beheben/ändern. Rein von der Funktionalität kann Git mindestens alles das was RCS auch kann.
Ich würde mir beim Entwickeln auch ungern "über die Schulter schauen lassen".
Aber bei Git hat man ja einen lokalen Server, auf dem man nach Lust und Laune "spielen" kann.
Erst, wenn das Ganze vorzeigbar ist, spielt man es vom lokalen auf den öffentlichen Server.
Warum nicht RCS -> CVS -> Git ? Das ist zwar extrem bekloppt aber sollte gehen, es gibt RCS -> CVS importer und CVS -> Git klappt ja auch.
Die ganze Doku für RCS -> CVS ist zwar richtig alt aber das sollte ja trotzdem noch gehen auch wenn heute schon CVS veraltet ist. Das sollte sich ja auch automatisieren lassen.
Im schlimmsten Fall hätte ich selbst etwas programmiert. Aber das alles kann nicht funktionieren, wenn man von Klaus keinen Zugang zum RCS Repository bekommt.
Ich habe ja nix dagegen, wenn er das Git Repository bei sich selbst hosten möchte. Aber zuerst brauche ich mal vollständigen Zugang zu irgendeinem RCS Stand von dem aus ich dann eine Lösung zur Echtzeitkonvertierung finden kann. So das Klaus weiter mit RCS programmieren kann, aber alle anderen trotzdem Zugriff auf ein modernes VCS haben.
Ich frag mich halt, wozu das gut sein, wenn Klaus erstens allein am VDR programmiert und zweitens eh sein RCS benutzt. Welchen Vorteil soll das ganze dann in GIT haben? Jeder der einen Patch einreichen möchte, kann sich die aktuelle VDR Version ins sein eigenes GIT schieben und daran arbeiten.
Klaus macht doch öfters Developer Releases. Wir sind zum Beispiel schon beim 6. Developer Release der 2.3 Branch. Könnte man nicht einfach diese als Grundlage für ein git für VDR Core nehmen? Wenn ich richtig verstanden habe, hätte Klaus nichts dagegen, wenn es so gehandhabt würde.
Auf diese Weise, könnten Personen Patches für den VDR Core über dessen git anbieten und es gäbe auch endlich einen Bugtracker für den VDR Core.
Außerdem, frage ich mich, ob es wirklich einen so großen Unterschied machen wird, wenn der öffentliche VDR Core git nur ein "Sammelcommit" mit den Änderungen der Developer Release hat, anstatt die einzelnen Commits die Klaus in sein RCS schreibt.
Eigentlich ist das Thema bezüglich den Commits von Klaus für mich abgeschlossen. Soweit ich verstanden habe, möchte er so weiterarbeiten wie bislang. Folglich würde ich vorschlagen, dass wir uns einfach daran halten und falls er seine Meinung ändert, werden wir es wahrscheinlich schon erfahren.
Auf diese Weise, könnten Personen Patches für den VDR Core über dessen git anbieten und es gäbe auch endlich einen Bugtracker für den VDR Core.
Aber genau das funktioniert mit der Plattform github nicht. Nicht das man nicht nur keine vernünftiges "tar.gz/bz2" mal eben über die Webseite bekommt, nur ZIP 
, man kann sich auch keine Commits als Patch darstellen lassen.
Das läuft vdr-developer.git mit Redmine deutlich besser, Commits kann man sich mit einem Klick als Patch anzeigen lassen, "tar.gz/bz2" wird für jeden "Status" direkt angeboten.
Wer will denn schon jedesmal einen clone machen bloß weil er einen Commit als Patch möchte ... oder erst ein kryptisches wget für ein tar.gz-ball ...
Regards
fnu
Nicht das man nicht nur keine vernünftiges "tar.gz/bz2" mal eben über die Webseite bekommt
Da gibt es mehrere Möglichkeiten - zum einen getaggte Releases wie z.B. bei https://github.com/horchi/vdr-plugin-osd2web/releases
Oder wenn man den aktuellen Stand eines Branch haben will, tauscht man bei der URL das *.zip durch ein .tar.gz aus (das funktioniert auch für Tags und bestimmte Commits):
https://github.com/horchi/vdr-plugin-osd2web/archive/master.zip
# wird zu
https://github.com/horchi/vdr-plugin-osd2web/archive/master.tar.gzOder man nutzt git archive in einem lokal geclonten Repo.
man kann sich auch keine Commits als Patch darstellen lassen
Wenn einem die typische Detailansicht für den Commit nicht genügt, kann man an die URL einfach ein ".diff" anhängen, um ihn als Patch zu erhalten - z.B. für https://github.com/horchi/vdr-…69493042cf144f36f327d9c46 den Patch: https://github.com/horchi/vdr-…042cf144f36f327d9c46.diff
Da gibt es mehrere Möglichkeiten
Genau, super intuitiv 
aber im Gegenzug immer wieder die Mausschubser Keule "Pull-Request" anbringen ... 
kann man an die URL einfach ein ".diff"
Ein Diff, ..., ein Patch hat für mich auch einen Header ... :
=> https://projects.vdr-developer…4bfd5d6d9341f6f15bd96223b
Und diesen tollen Pull-Request gibt prinzipiell auch bei jedem anderen GIT repo.
Nein, github ist nicht die tolle Lösung, ich finde vdr-developer.git besser. Was fehlt ist das intuitive Anmelden und die selbstverwaltung der SSH Keys. Letzteres läßt sich lt. eTobi mit einem Plugin umsetzen, evtl. redet man einfach mal nur mit Ihm ...
Regards
fnu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
