Alles, was hier geäussert wird, ist schön und gut - und geht imho teilweise am Thema vorbei. Ist aber nur so meine Meinung. Ein paar wesentliche Punkte sind schon angesprochen worden. Nach meiner Meinung nach aber nicht hart genug. Das wären:
a) Zielgruppe: Wer soll eigentlich rolling benutzen - derjenige mit mehr als nur ein wenig Sachverstand oder jemand, der eher ein rollendes Kuschellinux haben will. Das ist imho entscheidend für die Wahl der Basis mit allen Folgeproblemen. Weiterführend, was will ich erreichen: Im Moment zeichnen sich in meinen Augen einige Vorschläge durch: Wasch mir mein Fell, aber mach mich nicht nass! aus. Das wird so nicht auf Dauer funktionieren.
b) DonKult hat es angesprochen - die Klassiker der Rolling Releases zeichnen sich durch Selbstbeschränkung aus. Es ist illusorisch, den vollen Paketumfang und alle Architekturen rollend anzubieten. Deshalb kommen z.B. Arch oder PCL gut und vor allem aktuell daher. Max. 2 Architekturen müssen reichen, alles andere ist Zeitverschwendung - wer was anderes will, soll zusehen, wo er bleibt und selbst porten. Ist nicht unbedingt nett, macht die Sache aber erst möglich. Wie vereinbart sich dieser Ansatz mit debian?
c) Stabilität: Ich bin immer noch der Meinung, dass Rolling rechts von Sid angesiedelt werden sollte, das würde einige gravierende Probleme lösen, aber auch bringen ( old - stable - testing - sid - rolling - experimental). Das Problem mit der Aktualität hätte man nicht mehr, die Problematik Freeze würde wegfallen. Allerdings wäre dieser Ansatz wirklich bleeding, was die mögliche Zielgruppe wirklich drastisch eingrenzen dürfte. Der Nutzen für debian wäre aber, dass die Pakete schon aktuell und vorgetestet nach Sid kommen würden, so dass der Mehraufwand eines zusätzlichen Repos durch weniger Aufwand in Sid und Testing kompensiert werden würde. Der Ansatz von PPAs (oder halt temporären Repos) ist insofern alter Wein in neuen Schläuchen, da es ja schon den Mechanismus der Snapshots gibt. (Oder nennen wir das mal zweckgebundenes Repo). Wenn das so sein würde, wäre aber für Aptosid nichts gewonnen, da ja hier auf der Fahne steht, sid besser nutzbar zu machen. Das würde einfacher werden, der Grundzustand würde aber z.B. während der Freezes gleich bleiben. Auf Deutsch: in den Po gekniffen.
d) Benutzbarkeit: Irgendwo müssen die heftigen Pakete aufschlagen und einem breiteren Auditorium zugänglich gemacht werden. Unter dem Gesichtspunkt kann ich solche Sachen wie udev und perl sehr gut nachvollziehen. Wenn so was dann in rollend, wo es meiner Meinung nach hingehört, aufschlagen würde, würde es die Zielgruppe noch mal eingrenzen, das Ziel eines dauerhaft benutzbaren Sid (CUS) wäre aber wesentlich einfacher zu realisieren. Durch einen nicht stattfindenden Freeze würde sich die Lage auch entspannen, da permanent integriert werden könnte. Das alles dann aber benutzbar zu halten, schließt von vorn herein eine angedacht Zielgruppe aus, die wäre schlicht überfordert. Das würde so zwar geil und aktuell werden, aber auf keinen Fall zum kuscheln.
Trotz allem würde mir eine solche Einordnung sehr gut gefallen, da in den laufenden Betrieb und das Ziel, eine möglichst stabile Distribution zu entwickeln, sehr wenig eingegriffen werden würde. Wenn sich so was etablieren würde, könnte das auch den Entwicklungsprozess bei debian drastisch beschleunigen und z.B. kürzere Freezes möglich machen. Man müsste nur recht hart im Nehmen sein, um eine auf solche Art und Weise gestrickte Distribution wirklich auch im täglichen Betrieb einzusetzen. Auf dem Desktop würde ich das ja machen, dann immer mit Sid oder Testing als Fallback, aber so was hätte striktes Serververbot.