Hallo, * Markus Raab ([EMAIL PROTECTED]) [050326 11:30]: > Die Anzahl der Architekturen und riesige Anzahl der Pakete ist doch > genau das was Debian ausmacht. Dass der stable Zweig deshalb nicht > topaktuell sein kann, mag zwar in einigen Bereichen ein Nachteil sein > (welchen meiner Meinung nach mit guten Backports ausgleichen kann, Lob > an www.backports.org), in anderen Bereichen ist aber genau das ein > unsch�tzbarer Vorteil (keine Kinderkrankheiten, seltene Releases,...). > > Wenn Debian das verlieren w�rde, k�nnte ich es ja gleich runterschmei�en > und mit $DISTRI auswechseln, den Unterschied w�rde man nicht merken.
nun ja, es gibt Diskussionen, wie man Debian verbessern kann. Es gab dazu einen Vorschlag, der darauf hinauslaeuft, das wir (erstmals) bestimmte Kriterien fuer einen Port festsetzen; welche das sind, darueber gibt es derzeit noch (viele) Diskussionen. Fuer Details, bitte auf http://lists.debian.org/debian-devel-announce und http://lists.debian.org/debian-devel nachlesen. So ein Kriterium ist beispielsweise "wenn ein buildd ausfaellt, dann kommt die Architektur immer noch mit"; ein anderer ist "wir haben Porter, die sich beispielsweise um kernel und toolchain kuemmern". Mal ein Beispiel, was nicht sein kann: Seit 3 Wochen ist der schnelle arm-buildd kaputt; wir telephonieren derzeit dem lokalen Admin hinterher, und ueber 150 Pakete (Anzahl der Sources gezaehlt) kommen derzeit deswegen nicht nach sarge. Letztlich habe ich einfach keine Lust mehr, sowas fuer etch auch zu tun. (Und, wenn die Leute, die eine Architektur wollen, es nicht schaffen, ausreichend buildds zu betreuen, was soll man dann tun?) Anderes Beispiel: Der letzte sarge kernel security update hat zwei Monate gedauert, weil sich niemand fuer den Kernel auf sparc zustaendig gefuehlt hat. Auch da kann ich nur sagen: Es kann nicht Aufgabe des Release-Teams sein, bei sowas einer Architektur hinterherzulaufen. Wenn die Leute, die eine Architektur betreiben, das gut tun (mal ein paar positive Beispiele: mips*, m68k), dann spricht aus meiner Sicht alles dafuer, die Architektur zu behalten. > Was meint ihr dazu? Nur wegen einem Aussetzer (Sarge h�tte schon vor > einiger Zeit ohne den neuen Installer rauskommen sollen), kann man ja > nicht das Kind mit dem Bade aussch�tten. Nun ja, das Problem ist nicht "ein Aussetzer", sondern das einige (wenige) Architekturen deutlich mehr Zeit verbrauchen als alles andere fuer das Release Management. Wenn ich mir anschaue, was die nervigsten Probleme so sind: 1. Verfolgen, welche Bugs in sarge noch offen sind, aber nicht mehr in sid 2. Architekturen hinterherlaufen (kaputte toolchain, kaputte buildds, ...) 3. API-transitions und RC-bugs (da gibt es dann ganz grosse dependency-Ketten, die auf einen Schlag rein muessen) 1. wird durch ein update des bug tracking systems geloest werden (Code ist schon da, aber das Anschalten dessen wartet darauf, bis wir wirklich im Freeze sind). 3. wird durch eine Aenderung der testing-migration-Skripte geloest. 2. ist der Punkt, ueber den gerade diskutiert wird. Wir muessen ihn loesen, wenn wir nicht ein vollkommen neues Release Team wollen (und ich sehe niemanden, der faehig ist und ohne 2. bereit waere, das zu tun - dazwischen gibt es auch eine gewisse Korrelation :). Wobei aber die Diskussion gezeigt hat: Alle vorgeschlagenen Kriterien (mit einer einzigen Ausnahme[1]) koennen von allen Architekturen erfuellt werden, die derzeit in sarge sind - nur, das ist dann nicht mehr die Aufgabe des Release Teams, sondern der entsprechenden Porter. [1] da das aber alles Vorschlaege sind, und dieses Kriterium besonders unbeliebt ist (maximal 2 buildds koennen mit unstable Schritt halten), koennte gut sein, das das wegfaellt. Gruesse, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
