Re: Debian nur noch 4 Architekturen
Hallo,
* Markus Raab (markus.raab@aon.at) [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
Reply to: