rc Bugs, stable und testing

[tobb]

Hallo,

ich habe gerade den Graphen für die rc Bugs gesehen und da kam mir eine Frage auf:
http://bugs.debian.org/release-critical/
Mit welchem Recht nennt sich etch stable, wenn es bald dreimal so viele rc bugs hat wie lenny?

Kann man da nicht sagen, dass lenny (jetzt wo es gefreezed ist) schon stabiler ist als etch?

[jhr-online]

Manchmal hilft die Forensuche... :-/

Etch darf sich stable nennen, weil es mal vom Release-Team so entschieden wurde. Zu dem Zeitpunkt war der RC-counter von Etch auf 0. Dass das jetzt nicht mehr der Fall ist, liegt wohl daran, dass Leute dann doch noch Bugs gefunden haben. Das lässt sich wohl nicht vermeiden. Aufgrund der Tatsache, dass Etch stable ist, dürfen die Bugs nicht behoben werden; jede neue Zeile Code könnte schließlich wieder Bugs enthalten und stable heißt nicht stable, weil man da neuen Code ausprobieren soll... Einzige Ausnahme: Security Bugs. Die werden behoben in Stable.

jhr

[tobb]

Naja, was hätte mir die Forensuche geholfen?

Wie sich das mit stable und testing verhält, habe ich im Grunde schon verstanden.
Nun ist es doch aber so, dass die beschrieben Situation einen Widerspruch ausweist. Eine Version heißt stable und weist mehr gefunden rc bugs auf, als die Version mit Namen testing.
Was ich nicht wusste ist, dass Bugs in stable nicht gefixed werden dürfen. Das würde den Widerspruch halbwegs erklären.
Allerdings ist es doch so, dass die blaue Linie im Graphen (für etch) hoch aber auch wieder runter geht. D.h. es wird doch etwas gefixed. Oder sind das nur die Sicherheitsfixes?

Außerdem ist es doch dann rein objektiv gesehen schwer zu widerlegen, wenn jemand jetzt sagt: Lenny ist stabiler als Etch.

[gms]

Was ich nicht wusste ist, dass Bugs in stable nicht gefixed werden dürfen. Das würde den Widerspruch halbwegs erklären.
Allerdings ist es doch so, dass die blaue Linie im Graphen (für etch) hoch aber auch wieder runter geht. D.h. es wird doch etwas gefixed. Oder sind das nur die Sicherheitsfixes?

natürlich werden auch Fehler in der aktuellen Stable gefixt, das würde ja sonst die ganzen Fehlerberichte ad absurdum führen. Es gibt aber noch zusätzlich eine Bewertung des Veröffentlichungsteams, wo nach Schweregrad des Fehlers und wahrscheinlich auch nach dem Risiko durch den neuen Upload unterschieden wird:
http://www.jp.debian.org/releases/propo ... es.de.html

Außerdem ist es doch dann rein objektiv gesehen schwer zu widerlegen, wenn jemand jetzt sagt: Lenny ist stabiler als Etch.

von der meßbaren Größe, der Anzahl der RC-Bugs ist das sicherlich schwer zu widerlegen, allerdings ist Etch schon längere Zeit im produktiven Einsatz und Lenny wurde erst kürzlich überhaupt "gefreezed"

Gruß
gms

[MarkusF]

Naja, was hätte mir die Forensuche geholfen?

Ich denke, jhr-online hatte da u.a. den Thread hier im Sinn.
http://www.debianforum.de/forum/viewtop ... 5&t=102638
Ich hab's erst auch nicht verstanden aber die Erklärung in dem Thread war dann recht erleuchtend.

Außerdem ist es doch dann rein objektiv gesehen schwer zu widerlegen, wenn jemand jetzt sagt: Lenny ist stabiler als Etch.

Naja. Auch wenn der RC-counter bei Lenny hoffentlich bald auf 0 steht warten ja noch hunderte Bugs darauf entdeckt zu werden.

Grüße, Markus

[gms]

sehe gerade, in dem geposteten Link gibt es einen Übersetzungsfehler:

Bevor Sie ein Paket nach »proposed-updates« (»oldstable-proposed-updates«) hochladen, wären wir Ihnen dankbar, falls Sie die folgende Punkte beachten könnten:
Die Fehler, die behoben werden sollen, sind (werden) im BTS eingetragen
Die Korrekturen für die Fehler sind zumindest in Sid gründlich getestet
Die Patches
beheben ein Sicherheitsproblem, oder
beheben einen kritischen Fehler, oder
beheben eine Instabilität, einen -Fehler, oder
synchronisieren die Pakete in den Architekturen wieder
...
Im Zweifelsfall oder bei Fragen zögern Sie nicht, das Stable Release Team zu kontaktieren, Ihr Fall könnte durchaus die Ausnahme zu den eben beschriebenen allgemeinen Regeln darstellen.

vs

Before uploading a package to “proposed-updates” (“oldstable-proposed-updates”) it would be appreciated if one goes through the following checklist:
bug(s) one wants to fix in the upload is (are) filed in the BTS
the fixes for the bugs have been thoroughly tested at least in sid
patches
fix a security issue, or
fix a critical bug, or
fix an installability, an FTBFS bug, or
bring architectures back in sync
...
In case of doubt or questions, don't hesitate to contact the Stable Release Team, your case might always be an exception to the general rules of the above checklist!

das fehlende Wort ist also FTBFS ( failed to build from source )

Gruß
gms

[jhr-online]

Außerdem ist es doch dann rein objektiv gesehen schwer zu widerlegen, wenn jemand jetzt sagt: Lenny ist stabiler als Etch.

Nein, das ist falsch. Zu Stabilität gehört auch, dass das System nicht täglich geändert wird, und das ist bei Lenny der Fall. In den letzten Wochen gab es mehrfache Kernel-Fixes, sogar ein neuer Kernel ist noch im Freeze reinkommen. Jemand, der auf ein stabiles System setzt, kann nicht täglich irgendwelche Dienste (und eben manchmal sogar das ganze System) neu starten müssen.
RC-Bugs dürfen keine drin sein, aber das ist nur ein Release-Goal und nur ein Anspruch an ein stabiles System.

jhr