Automatic removal of packages from testing

[catdog2]

Da bin ich mal gespannt wie sich das auswirkt.

Auto-removals
=============

As we announced, we are going to start automatic removals from testing
of some RC buggy packages, to help lower the number of outstanding RC
bugs which affect the jessie release. We would like to emphasise that
we obviously prefer to have fixes for the outstanding RC bugs, and
that (auto)removing packages is only used as a last resort.

Packages which have RC bugs that are present in both testing and
unstable, and which have no recent activity (currently this means no
activity in the last 14 days) will be checked for removal.

If the packages are on the list of "key packages"[KEY-PACKAGES], they
will be excluded from automatic removal. Also packages which have
reverse (build-)dependencies in testing, will currently also be
excluded from automatic removal.

Should your package suffer from an RC bug which needs more time to get
fixed, the specific bug can be temporarily whitelisted. Please file a
bug against release.debian.org with an explanation for the delay;
these exceptions will granted on a case-by-case basis.

For packages which are marked for autoremoval 10 days in a row,
removal hints will be added. These packages will usually be removed
from testing fairly soon after that. You can see if any of your
packages might be candidates for removals at [AUTO-RM-CANDIDIATES].
We activated the auto-removals at the time of this announcement,
however until the 2013-10-15, the usual autoremoval delay of 10 days
will be extended to 15 days, so you have some time to fix any
outstanding issues.

If packages get autoremoved from testing, they can get back in when
the RC bugs are fixed, using the same rules that apply to other
packages. In most cases, this means that the fix can get back into
testing after the usual 10-day waiting period.

Please note that packages which are excluded from automatic removal
could still be manually removed from testing.

We would like to thank Ivo De Decker writing the actual implementation
for finding these auto-removable packages.

Niels, on behalf of the Release Team.

[KEY-PACKAGES]
http://udd.debian.org/cgi-bin/key_packages.yaml.cgi

[AUTO-RM-CANDIDATES]
http://udd.debian.org/cgi-bin/autoremovals.cgi
"dd-list"-like of packages considered for auto removals.

For automatic processing, use
http://udd.debian.org/cgi-bin/autoremovals.yaml.cgi

[rendegast]

... your package ...

Ich hoffe ja, daß popularity-contest da eine gewisse Tendenz verursacht,
"mein" Paket nicht rausfliegen zu lassen.

[MrGerardCruiz]

Also manchmal fragt man sich echt, was die da machen. Das würde mein halbes System über den Jordan jagen. So langsam überlege ich wirklich mit 13.10 auf Kubuntu zu migrieren.

[Radfahrer]

Dann nutze doch einfach kein Testing. Der Name hat schon seine Bedeutung.
Außerdem frage ich mich, wie dein System so läuft, wenn es zur Hälfte aus kaputten Paketen besteht.

[KBDCALLS]

Es ist ja eine Frage der Definition was man als kaputt ansieht.

[hikaru]

Packages which have RC bugs that are present in both testing and
unstable, and which have no recent activity (currently this means no
activity in the last 14 days) will be checked for removal.
[..]
For packages which are marked for autoremoval 10 days in a row,
removal hints will be added. These packages will usually be removed
from testing fairly soon after that.

Urlaube von mehr als drei Wochen Länge sind also ab nächster Woche für Debian-Maintainer gestrichen?
xxxterm (718074) würde mir fehlen ... also langfristig ... so ab Jessie-Release.

[MrGerardCruiz]

Dann nutze doch einfach kein Testing. Der Name hat schon seine Bedeutung.
Außerdem frage ich mich, wie dein System so läuft, wenn es zur Hälfte aus kaputten Paketen besteht.

Nur weil es in den Paketen angeblich RC Bugs gibt, heißt das nicht, dass jeder davon betroffen wäre. Von einem Verlust der Pakete in testing wäre aber jeder betroffen.

[Radfahrer]

Nein, davon wären nur die betroffen, die Testing nutzen. Nicht jeder.
Wie gesagt, wenn man Testing nutzt, muss man wissen, worauf man sich einlässt. Dieser Zweig ist zum Testen da. Deswegen heißt das so. Wer also nicht testen will, Fehler suchen will und Bug-Reports schreiben will, sollte es nicht nutzen. Punkt.

[MrGerardCruiz]

Nein, davon wären nur die betroffen, die Testing nutzen. Nicht jeder.
Wie gesagt, wenn man Testing nutzt, muss man wissen, worauf man sich einlässt. Dieser Zweig ist zum Testen da. Deswegen heißt das so. Wer also nicht testen will, Fehler suchen will und Bug-Reports schreiben will, sollte es nicht nutzen. Punkt.

Sinnfragen hast du dir noch nicht gestellt oder? Der Jessie Release ist meilenweit entfernt, welchen positiven Effekt hat das Rauswerfen von Paketen jetzt aus Testing?

[Radfahrer]

Vielleicht den, dass die Softwareentwickler mal ein bisschen Gas geben, damit ihr Kram wieder aufgenommen wird? Manche brauchen eben mal einen Tritt in den Hintern.

Und Software die buggy ist und eh nicht richtig gepflegt wird, kann von mir aus auch gerne rausfliegen.

[inne]

Packages which have RC bugs that are present in both testing and
unstable, and which have no recent activity (currently this means no
activity in the last 14 days) will be checked for removal.
[..]
For packages which are marked for autoremoval 10 days in a row,
removal hints will be added. These packages will usually be removed
from testing fairly soon after that.

Urlaube von mehr als drei Wochen Länge sind also ab nächster Woche für Debian-Maintainer gestrichen?
xxxterm (718074) würde mir fehlen ... also langfristig ... so ab Jessie-Release.

Ich finde die Zeiten auch sehr kurz gehalten.

Ausserdem was heisst fliegen raus? In unstable bleiben die doch erhalten, bis sich jemand drum kümmert? Von dort können die ja ggf. nach Testing gebackported werden (Sollte doch ohne Probleme machbar sein, wenns noch die selbe verbuggte Version ist die vorher auch in Testing war). Und was man hat, sollte man pinnen. Kann apt-listbugs das nicht sogar autom. tun?
Dann wird stable ja mal zu dem was man machmal fälschlicher Weise über stable hört: Frei von Bugs. Anstatt stabile Abhänigkeiten incl. Versionen. Grundsätzlich bin ich davon nicht abgeneigt, nur ob man so ein brauchbares release hinbekommt...
Wirklich ein spannendes Experiment.

[inne]

Hat das eigentlich langfristig gedacht Auswirkungen auf den Lebenszyklus von stable?
Wenn so die RC-Bugs gedrückt werden sollen, könnte man vermuten das in kleineren Intervallen stable Veröffentlichung herauskommen.

Edit: Gibt es eine min. Lebenszeit für stable?

[sidloki]

Hat das eigentlich langfristig gedacht Auswirkungen auf den Lebenszyklus von stable?
Wenn so die RC-Bugs gedrückt werden sollen, könnte man vermuten das in kleineren Intervallen stable Veröffentlichung herauskommen.

Edit: Gibt es eine min. Lebenszeit für stable?

Das ist wohl auch der Sinn der Sache. Testing so weit wie möglich frei von RC-Bugs zu halten, so dass ein Release schneller über die Bühne geht. Keine monatelangen Freezes mehr, wär sicher wünschenswert.

Allerdings heisst das nicht, dass Debian deswegen öfter released wird.

Um Probleme in testing zu vermeiden, empfehle ich unstable in die sources.list aufzunehmen und auf 400 zu pinnen (oder testing 900 und unstable 800?)

[bmario]

Aber euch ist schon bewusst, dass Pakete die nicht mehr im Repository zu finden sind, deswegen nicht gleich bei euch lokal deinstalliert werden?

[Henrikx]

Aber was nützt das?
Bei meinem Notebook funktioniert der sis Treiber nicht mehr auch nicht der aus sid.

Als Abhängigkeit wird folgendes angegeben.
dep: xorg-video-abi-8 [hppa]
virtuelles Paket, bereitgestellt durch xserver-xorg-core, xserver-xorg-core-udeb

Egal was ich versucht habe, ich habe den Treiber nicht kompiliert bekommen, weil er auch in sid buggy ist.
Mittlerweile kann ich einige Entscheidungen bei Debian nicht mehr nachvollziehen.

PS: Ich schreibe hier den Text mit dem Notebook, dass ich nach der Definition von Debian in die Tonne hauen kann.Dafür musste ich die Distribution wechseln.

[catdog2]

Was hat debian damit zu tun, dass dieser Treiber kaputt ist? Vermutlich kümmert sich upstream keiner mehr um diesen Exoten. (Bugreport verfasst?)

[Henrikx]

Gegenfrage : Wieso ist der Treiber nur bei Debian kaputt?

[KBDCALLS]

Geht es um diesen xserver-xorg-video-sis

Falls ja dann ist der letzte 0.10.7

[bmario]

Gegenfrage : Wieso ist der Treiber nur bei Debian kaputt?

Gegengegenfrage: Warum willst du den Treiber überhaupt kompilieren, anstatt das fertig kompilierte Paket zu nutzen?

[Henrikx]

Weil das Paket nicht mehr funktioniert.
Außer VGA war nichts mehr zu machen..
Kompilieren zwecklos, egal ob Source/Abhänigkeiten aus testing oder sid Quellen.

@KBDCALLS
Genau.
z.B in Arch ist 2013-03-10 upgpkg: xf86-video-sis 0.10.7-4 und funktioniert tadellos.
Wieso also nicht bei Debian?

[Teddybear]

Weil das Paket nicht mehr funktioniert.
Außer VGA war nichts mehr zu machen..
Kompilieren zwecklos, egal ob Source/Abhänigkeiten aus testing oder sid Quellen.

@KBDCALLS
Genau.
z.B in Arch ist 2013-03-10 upgpkg: xf86-video-sis 0.10.7-4 und funktioniert tadellos.
Wieso also nicht bei Debian?

Fage doch einfach mal den Maintainer warum da nix neueres nachkommt.
Oder bau dir den 0.10.7 einfach selbst..

Und zu deiner Frage wieso der Kaputt ist: der 0.10.4 der in sid rumdümpelt brauch xorg-video-abi-12, wir sind aber schon bei 14.

[Henrikx]

@Teddybear
Selbst bauen war nicht möglich, bzw. ich bin jedenfalls daran gescheitert.
Wie gesagt, ich habe jetzt Arch aufgezogen und es funktioniert gut.
Fühle mich zwar ein wenig von Debian wie vor die Tür gesetzt, aber was soll es, interessiert eh niemanden.
Ich kann auch nicht der Argumentation folgen, testing ist ein gefährliches System.
Bin seit Jahren auf testing, so was ist mir noch nie passiert.

Arch core läuft ebenfalls sehr zuverlässig.
Sollte sich der bis jetzt positive Eindruck von Arch weiter bestätigen, würde ich alle meine Computer auf Arch umrüsten und fairerweise auch meinen Mod - Status abgeben. Bin z.Z. echt sauer...

Einen Treiber zu entfernen und keinen Ersatz zu liefern, ist einfach nur dreist.

[rendegast]

Ich kann auch nicht der Argumentation folgen, testing ist ein gefährliches System.
Bin seit Jahren auf testing, so was ist mir noch nie passiert.

Und jetzt hat es Dich doch erwischt.

http://packages.ubuntu.com/xserver-xorg-video-sis
Ab saucy für video-abi-14

Der 0.10.7 wird wohl "upstream-experimental" / "upstream-unstable" getestet.

Solange alternativ sisfb (kernel) + fbdev (xorg)?

[KBDCALLS]

Weil das Paket nicht mehr funktioniert.
Außer VGA war nichts mehr zu machen..
Kompilieren zwecklos, egal ob Source/Abhänigkeiten aus testing oder sid Quellen.

@KBDCALLS
Genau.
z.B in Arch ist 2013-03-10 upgpkg: xf86-video-sis 0.10.7-4 und funktioniert tadellos.
Wieso also nicht bei Debian?

Und mal versucht die Originalquellen zu kompilieren ? Ohne das Debiandiff.

[Henrikx]

Du meinst 10.7.4?