Npq hat geschrieben:[...]
Für mich waren die Snapshots bislang Testversionen, die den CDK-Head-Stand wiederspiegeln oder eben einen bestimmten Stand, der aber ebenfalls per "cvs -r Summerheat-Revision" herstellbar ist.
Ich finde man sollte dann eine Trennung machen zwischen einem quasi Yadi-spezifischen Testimage und einem Snapshot. Ich habe nix dagegen wenn die Imageersteller selber ein bißchen experimentieren, nur sollte das dann auch für die CDK-Jungs klar erkennbar sein.
Gut, um das mal klar zu stellen:
Alle yadi-snapshots sind keine tuxbox-cvs-snaps im strengen Sinne. Sie sind Snaps eines Entwicklungsstandes der einerseits auf dem tux-cvs basiert andererseits auf dem yadi-cvs. Trotzdem sind es 'snaps' in dem Sinne, dass sie einen datierbaren Stand haben und auch später mit diesem Stand wieder herstellbar wären.
Wären es reine tuxbox-cvs-snaps, müssten die User auf nicht wenige Features verzichten, angefangen beim Enigma-TS-recording über Squashfs als File-System, die Auswahl alternativer Treiber bis hin, eben jetzt, zum Kernel 2.4.26. Ums mal überspitzt zu sagen: Echte Snaps gibt es eh nicht, da selbst das tux-cvs oft mehrere Alternativen bereitstellt.
Reine tuxbox-cvs-snaps machen für uns auch deshalb keinen Sinn, weil keiner der ImageDevs von dietmarW über jtg-riker bis zum Yadi-Team Schreibrechte im tuxbox-cvs hat, also nicht mal taggen könnte. Ansonsten wäre es kein Problem "unseren Stand" z.B per ifdef ins tux-cvs zu bugsieren, dann wäre es halt ein "echter snap".
Ich sehe aber durchaus Vorteile im Status Quo: Die Image-Macher müssen sich mit den Ideen der tuxdevs genauso auseinander setzen wie die tuxDevs mit denen der Imagemacher. Bisher hab ich das als sehr positiv erlebt, weiss nicht wie es dir, NPQ, z.B. geht, ich hoffe aber ähnlich.
Ausserdem: Niemand erwartet von den tux-devs, Yadi-Snaps zu supporten, selbst der Support durchs Yadi-Team ist da nicht zugesichert. Dass das trotzdem ganz gut klappt, ist, glaube ich, kein Zufall.
