-
Vorschlag: macht ein stabiles ffmpeg und dazu ein experimentelles ffmpeg-staging
Autor: lahmbi5678 03.08.15 - 07:24
Ähnlich wie bei wine und wine-staging sollte es zwei Arten von Releases geben, wer es maximal stabil möchte, nimmt den Standard-Release, wer die neuesten Features möchte, nimmt staging mit den neuesten Patches und Hacks. Das macht es dann auch für einen stabilitätsorientierten Maintainer leichter, er kann sich auf den stabilen Zweig konzentrieren, und muss nicht die Entwickler verärgern, die neue Ideen einbringen wollen. Wahrscheinlich müsste man für den Staging-Zweig einen anderen Maintainer bestimmen, weil staging sich immer ein bisschen im Konflikt mit dem stabilen Zweig befinden wird, denn unproblematische Patches kommen ja leicht in den stabilen Zweig.
Mit einem solchen Modell hätte der Niederreiter nicht zurücktreten müssen, zumindest nicht ganz. -
Re: Vorschlag: macht ein stabiles ffmpeg und dazu ein experimentelles ffmpeg-staging
Autor: metal1ty 03.08.15 - 08:10
lahmbi5678 schrieb:
--------------------------------------------------------------------------------
> Ähnlich wie bei wine und wine-staging sollte es zwei Arten von Releases
> geben, wer es maximal stabil möchte, nimmt den Standard-Release, wer die
> neuesten Features möchte, nimmt staging mit den neuesten Patches und Hacks.
> Das macht es dann auch für einen stabilitätsorientierten Maintainer
> leichter, er kann sich auf den stabilen Zweig konzentrieren, und muss nicht
> die Entwickler verärgern, die neue Ideen einbringen wollen. Wahrscheinlich
> müsste man für den Staging-Zweig einen anderen Maintainer bestimmen, weil
> staging sich immer ein bisschen im Konflikt mit dem stabilen Zweig befinden
> wird, denn unproblematische Patches kommen ja leicht in den stabilen Zweig.
>
> Mit einem solchen Modell hätte der Niederreiter nicht zurücktreten müssen,
> zumindest nicht ganz.
Genau..noch eine Version...Am besten direkt einen Fork. Davon gibts noch nicht genug....! Ich bitte dich. -
Re: Vorschlag: macht ein stabiles ffmpeg und dazu ein experimentelles ffmpeg-staging
Autor: lahmbi5678 03.08.15 - 08:35
Naja, bei wine kommt sowohl wine als auch wine-staging von praktisch denselben Leuten. Es ist also kein Fork in dem Sinne, daß sich Leute gegenseitig hassen oder beharken. Bei wine hört man nur, daß der Maintainer und zwei, drei Core-Entwickler über wine-staging nicht ganz glücklich sind, wahrscheinlich weil es extra Arbeit macht und den Geschäftsbetrieb (Codeweavers) stört, alle anderen freuen sich, daß es ein offizielles Testfeld gibt. Der Vorteil von staging ist, daß Patches von einer Vielzahl von Anwendern getestet werden (Ubuntu z.B. setzt auf staging) und der Maintainer nach einer gewissen Zeit, in der sich ein Patch bewährt hat, oft überredet werden kann, den Patch in den normalen Release aufzunehmen (der bei wine unstable heisst, stable gibt's nur alle paar Jahre mal).
1 mal bearbeitet, zuletzt am 03.08.15 08:36 durch lahmbi5678. -
Re: Vorschlag: macht ein stabiles ffmpeg und dazu ein experimentelles ffmpeg-staging
Autor: humpfor 03.08.15 - 13:04
Stable und instable releases sind kein Fork..
-
Re: Vorschlag: macht ein stabiles ffmpeg und dazu ein experimentelles ffmpeg-staging
Autor: lahmbi5678 03.08.15 - 13:19
In wine-staging sind aber auch Patches drin, die der Wine-Maintainer in den nächsten Jahren nicht in das vanilla wine lassen wird, egal ob stable oder unstable, weil sie spezifisch auf bestimmte Anwendungen/Spiele zugeschnitten sind oder zu sehr Hack im SInne von "nicht langfristig wartbar".
Im wine Projekt gab es früher(tm) öfter Situationen, daß Patches ein Problem lösten, dann aber, wenn in verwandten Bereichen andere Probleme gelöst werden sollten, erheblicher Mehraufwand entstand, weil die früheren Patches die Probleme eben nicht 100% Windows kompatibel gelöst haben, so daß dann viel Nacharbeit nötig war. Daher will der Maintainer nur 100% konzeptionell saubere Patches. -
Re: Vorschlag: macht ein stabiles ffmpeg und dazu ein experimentelles ffmpeg-staging
Autor: spiderbit 03.08.15 - 13:39
die dann allerdiengs ausschliesslich auf nvidia hin optimiert sind und oft nur damit sauber laufen ob man das konzeptionell sauber nennen will weiss ich nicht.
Und nein das sind dann meistens nicht bugs im amd treiber, oft werden die bugs im nvidiatreiber mit einprogrammiert quasi, und weil der nvidiatreiber sich vielleicht irgendwo nicht an der standart sauber haelt und wine darauf ein geht laeuft das dann mit einem treiber der sauber ist unter umstaenden nicht.



