~testing -> stable Kriterien/Richtlinien?

[andi_s]

Hallo,

ich habe erfolglos versucht irgendwo eine Info darueber zu finden nach welchen Kriterien bei Gentoo die Packages von ~testing auf stable gesetzt werden.

Wie wird das hier mit ~testing -> stable gehandhabt, d.h. wer entscheidet das und nach welchen Kriterien/Richtlinien wird entschieden?

Danke

[franzf]

Naja, ausgiebig getestet sollte es sein, heißt ausreichend lange im Portage verfügbar sein (>1 Monat).
Keine neuen Bugs im Bugzilla über gewissen Zeitraum.
Security Fixes gehen schnell(er) stable.
Und natürlich ausreichendes "Interesse" bei den Maintainern

[Max Steel]

Oft sind die testingReleases bereits vom Releaser als stable gekennzeichnet und sitzen diese Zeit >1Monat nurnoch aus.
_________________
mfg
Steel
___________________

Heim-PC: AMD Ryzen 5950X, 64GB RAM, GTX 1080
Laptop: Intel Core i5-4300U, 16GB RAM, Intel Graphic
Arbeit-PC: Intel i5-1145G7, 16GB RAM, Intel Iris Xe Graphic (leider WSL2)

[jodel]

ich finde die stable Politik von Gentoo eigentlich gar nicht so schlecht, da ich aber auf meinem Zweitrechner Arch Linux verwende (auch eine Rolling Release Distro) fallen mir da doch ein paar Unterschiede auf, ohne dass ich die unbedingt bewerten will:
- bei Arch ist Chromium schon seit Ewigkeiten im Stable, bei Gentoo nicht.
- bei Arch ist seit gestern Kernel 2.6.33 stable, bei Gentoo haben wir noch 2.6.31
- lighttpd hat mit 1.4.26 einen wichtigen Security Bugfix bekommen, ist aber immer noch nicht stable in gentoo.

[franzf]

[jodel]

[andi_s]

Also gibt es keine konkreten Richtlinien, sondern die Maintainer machen das nach Gefühl und Zeit, wenn ich das richtig verstanden habe?

Allerdings wundert es mich das z.B. mozilla-firefox-stable (sicher ein Programm das 80% der User hier taeglich nutzen) noch immer bei Version 3.5.8 rumduempelt. (3.5.8 wurde am 17.2.10 released und 3.6 am 21.1.10.)
Bei dem Sprung von 3.5.x auf 3.6.x moegen neue Abhaengigkeiten die Sache zwar verzoegern, aber nun sind ja fast 3 Monate vergangen - das kommt mir doch schon recht langsam vor. Vor allem Minor-Versionsspruenge (3.6.0 auf 3.6.3 etc.) sollten doch eigentlich keine langen Testphasen mehr benoetigen, da es sich ja nur um Bugfixes handelt.

Beim Kernel kommt mir das aehnlich traege vor oder taeusche ich mich da, wenn ich das Gefuehl habe das Gentoo bei einigen Sachen inzwischen etwas hinter anderen Distributionen hinterherhinkt?

ps: Klar hindert einen Niemand daran einzelne Programme auf ~testing umzustellen, wenn es einem zu langsam geht, aber wenn man damit anfaengt kann man imho wegen der vielen Abhaengigkeiten gleich das ganze System auf ~testing umstellen. Mir ist auch bewusst das hier Freiwillige am Werk sind, also bitte nicht falsch verstehen.

[franzf]

[andi_s]

Ja, ist ja alles richtig...

.0er-Releases sind in der Tat meistens Betaversionen, wo der User testen darf - das war schon immer so - auch unter Windows sollte man davon die Finger lassen...

Ich denke nur das man in dem Moment wo FF 3.6.0 stable ist man eigentlich auch 3.6.3 relativ schnell freigeben koennte, da sich da ja i.d.R. kaum was aendert. Wenn man da auch die >1 Monat warten/testen Politik faehrt verliert man doch immer mehr an Boden zu z.B. Arch. Und FF ist imho eine Anwendung, die man immer auf neustem Stand halten sollte selbst wenn Sie nicht 100% stable ist. Daher habe ich mich halt gefragt ob es nicht sinnvoll waere gewisse 'stable'-Kriterien einzufuehren. Was ist schlimmer: Eine neue FF-Version, die vielleicht mal abstuerzt oder eine veraltete Version, fuer die diverse Exploits im Internet rumgeistern?
Was den Kernel angeht, da kann ich die Zurueckhaltung eher verstehen - der sollte schon richtig stabil sein, wobei .32 ja auch schon eine Weile draussen ist, allerdings kann ich das nicht wirklich beurteilen. Ich weiss nur das Arch nun schon bei .33 'stable' ist und da fragt man sich schon wieso Gentoo nicht wenigstens bei .32 ist.

Ich habe mal irgendwo gelesen das eine der staerken von portage sein soll, das man packages leichter wieder zuruecknehmen kann, wenn Sie Probleme verursachen. Warum nutzt man das nicht, indem man sowas wie Stabilitaetsklassen/Prioritaeten einfuehrt, d.h. bei manchen packages Aktualitaet vor Stabilitaet setzt? Falls es Probleme gibt koennte man die Pakete dann immernoch zurueckziehen. Das kann man zwar auch selbst indirekt ueber ~testing realisieren, aber wenn das zentral gemanaged werden wuerde faende ich das nicht schlecht.

Vielleicht bin ich auch nur zu ungeduldig, aber ich denke schon darueber nach mir mal Arch anzusehen, da Gentoo inzwischen immer mehr hinterherhinkt. Frueher war Gentoo sicher mit die aktuelleste Distribution, allerdings musste ich damals auch schmerzhaft erfahren was schlecht getestete Pakete anrichten koennen. Inzwischen gibt es kaum noch Probleme beim emergen - das ist sicher eine positive Entwicklung, aber irgendwie fehlt mir die richtige Balance zwischen Aktualitaet und Stabilitaet - ich denke da koennte man noch was verbessern oder empfinde nur ich das so?

[franzf]

Security Fixes finden im 3.5er Firefox aber schon noch statt. Oder wundert es dich nicht dass 3.6.0 im Januar erschienen ist, im Februar aber dann ein Update für 3.5 rauskam? Außerdem wird 3.6.0 NIE ein stable-firefox-Kandidat sein. Das ebuild ist ja schon längst nicht mehr verfügbar.
Im Übrigen findest du Bei Gentoo Security Fixes oft in Form von Patches und einer neuen Revision. Das fixed dann NUR das Sicherheitsloch, bringt aber keine neuen Unwägbarkeiten eines kompletten Versions-Upgrades mit an Bord.

Wenn du immer aktuell sein willst, solltest du überlegen, mal ACCEPT_KEYWORDS="~<mein_arch>" zu setzen. Das erspart dir das unkeyworden von Testing-Paketen, du wirst genau so aktuell sein wie bei Arch.

[cryptosteve]

Ich finde die Stabilisierungskriterien von Gentoo durchaus gelungen. Vor allem, wenn ich im IRC oder in den Foren berichte über massive Probleme beim emergen sehe, dann stelle ich fest, dass ich die hier in der Form unter stable nicht habe.

Entweder hab ich ein merkwürdiges System, nur Glück, oder der Stabilisierungsprozess hat ganz eindeutig seine Berechtigung.
_________________
- born to create drama -
gpg: 0x9B6C7E15
CS Virtual Travel Bug: VF6G5D

[Josef.95]

[Klaus Meier]

[schachti]

[cryptosteve]

[andi_s]

Das ist doch genau der Punkt... es gibt keine eindeutigen Richtlinien, ab wann man packages als stable bezeichnen kann. Daher sind bei gentoo packages in testing, die bei arch stable sind, obwohl es die gleiche Software ist...

Daher finde ich die Wahl zwischen 0 (testing) und 1 (stable) nicht unbedingt optimal. Ein System wo man die Balance systemweit irgendwo zwischen 0 und 1 austarieren koennte faende ich wesentlich sinnvoller. Eine Moeglichkeit waere z.B. so vorzugehen:

- Die Maintainer passen den Stabilitätsgrad des jeweiligen Packages dynamisch der Entwicklung an, d.h. Sie weisen dem package bei Neuerungen immer einen Wert zwischen 0% und 100% zu, wobei 0%==testing entspricht und 100%==stable (diese Werte sind natürlich auch gefühlte Werte und basieren nur auf der Meinung/Erfahrung des Maintainers)
- Der User koennte dann in der make.conf zwei Werte (fuer system & world) zwischen 0% und 100% definieren. Ich wuerde da z.B. fuer system=80% und world=60% waehlen, da ich auf ein rel. stabiles System Wert lege, aber bei Anwendungen aktuellere Versionen bevorzuge und bereit bin Probleme in Kauf zu nehmen.
- den Rest uebernimmt portage und merged nur packages die >= dem definierten Stabilitaetsgrad sind.

So koennte man viel flexibler definieren, worauf man Wert legt. system=80% wuerde dann bedeuten das man packages bekommt, die im Prinzip stabil sind, aber eben noch nicht als stable freigegeben wurden, weil der Maintainer vielleicht noch >1 Monat abwarten will.

Ein schoener Nebeneffekt waere das man so den aktuellen Stand der Dinge auf packages.gentoo.org verfolgen koennte (package ist bei 70% etc.) und man auch eine Datenbasis erhalten wuerde, die man auswerten koennte. D.h. man koennte anhand von Statistiken festellen ob die maintainer zu vorsichtig sind oder eben zu voreilig und dann seine make.conf entsprechend justieren...

Vielleicht liest das hier ja einer der Entwickler und denkt mal darueber nach - ist 'im Prinzip' ja relativ simpel und wuerde noch mehr Flexibilitaet bringen und das ist ja genau das was die Meisten an Gentoo moegen...

[franzf]

Solche Diskussionen gab es schon öfters.
Um es kurz zu machen:
Gentoo (und definitiv arch ebenso) würde die Manpower fehlen, so ein System durchzuziehen. Es gibt sinnvollere Felder auf die ein Dev Wert legen sollte.

Selbst eine einzige zusätzliche Stufe "nearly stable" zwischen stable und testing wäre vom Aufwand her nicht zu bewältigen. Denn wie willst du es mit den Abhängigkeiten machen?
kde-4.4 braucht gewisse Mindestanforderungen. kde-4.4.2 ist mittlerweise ziemlich stabil, läuft hier absolut rund. stable KANN man es nocht nicht bezeichnen. Jetzt existiert Abhängigkeit XYZ, die nur "testing" ist. Der Maintainer von XYZ sagt "es ist nicht sinnvoll XYZ schon als nearly stable zu bezeichnen". Was macht der kde-Maintainer jetzt bitte?!?
Oder aktuelles Beispiel: Dolphin hat nen Memory Leak in den thumnailers (glaub mplayerthumbs war das). Das heißt das Ding kann definitiv noch nicht nach nearly stable gehen. kdelibs sind aber definitv nearly stable-zauglich. Jetzt gibt es natürlich noch mehr Anwendungen als nur dolphin, die kdelibs brauchen. Z.B. konsole. Und die sind wiederum sehr wohl nearly stable-tauglich. Wenn man jetzt sagt "kdelibs + konsole -> nearly stable; dolphin -> testing" bekommt man einen richtig schön unüberschaubaren Wust.
-> unmaintainable, bei der Manpower die Gentoo hat.

[Necoro]

Außerdem: Wenn es schon an genauen Spezifikationen fehlt, ob ein Paket bei 0 (testing) oder 1 (stable) ist -- wie willst du denn die Prozentzahlen in der Mitte angeben? Das wird doch denn ein kruder Mischmasch aus den Bauchgefühlen der Maintainer ...

Und was machst du, wenn ein paket bei ... 0.8 steht und ein böser Bug auftaucht. Soll das denn zurückgestuft werden? Und du denn immer mit up- und downgraden beschäftigt sein?
_________________
Inter Deum Et Diabolum Semper Musica Est.

[Klaus Meier]

[Josef.95]

[Necoro]

[Josef.95]

@Necoro
Ein klein wenig kann man sich da ja auch zb nach den farbigen Sternchen in der "layman -L" Liste orientieren (rot gelb grün)
da gibt es doch enorme Unterschiede,
aber hast schon recht, es gibt da durchaus auch sehr gut und sauber geführte Overlays (zb auch "kde")

[cryptosteve]

[Klaus Meier]

Ok, nicht jedes Overlay ist unstable, aber wer unstable will, der kommt an den Overlays nicht vorbei....

Die package.mask wird aktuell dafür nicht mehr sehr oft genutzt.

[schachti]