Ich verstehe sowieso eines nicht:
Wenn AVM diverse Verbesserungen in ihren Laboren durchführen, warum basteln die an zuvielen Baustellen, die eigentlich ja in Ordnung scheinen.
Vielleicht ist das ja in Bezug auf den DSL-Treiber doch ein wenig die Sichtweise, wo der Tellerrand das Ende der "Weltscheibe" bildet ... wenn eine Version mit einer LineCard (Hersteller/Firmware) an einer Leitung (Länge, Dämpfung durch andere Faktoren, zusätzliche Störer wie Spikes oder "alien crosstalk") sehr gut funktioniert, dann muß sie das mit einer anderen ja noch lange nicht tun.
Wenn dann AVM weitere Änderungen vor- und vielleicht auch Kompromisse in Kauf nimmt, damit es nicht an der einen besonders gut und an der anderen besonders schlecht arbeitet und dabei das "besonders gut" auch wieder etwas schlechter wird, dann dürfte das für den durchschnittlichen Benutzer auch in seinem eigenen Interesse liegen.
Er weiß nämlich i.d.R. wenig bis nichts über seinen DSLAM und da wäre ein "Pech gehabt", weil es einer mit "besonders schlechter" Zusammenarbeit mit der FRITZ!Box ist, wohl kaum angemessen ... zumal er sich den DSLAM ja nicht aussuchen kann, aber die FRITZ!Box sehr wohl.
Wenn dann am Ende die Empfehlungen zum Beispiel lauten "Nimm für einen Broadcom-DSLAM besser keine FRITZ!Box.", was macht dann wohl jemand, der gar nicht genau weiß, daß/ob sein Anschluß an einem Broadcom-DSLAM hängt oder nicht (weil der Anschluß vielleicht sogar neu ist)? Der geht auf Nummer sicher und das heißt dann in der Konsequenz, der nimmt einen anderen Hersteller.
Wenn das DSL also bei Dir stabil und schnell ist, muß das für andere noch lange nicht gelten (so steht das jedenfalls auch in anderen Beiträgen hier, daß praktisch immer irgendjemand Probleme mit dem DSL hat) und da ist das Ansinnen an AVM, doch einfach nichts mehr am DSL-Treiber zu ändern, dann schon "komisch".
Wobei ich bei der Ansicht "zuviele offene Baustellen" sogar zustimmen würde. Das geht für mich (auch nur aus der "Außensicht" auf die Ergebnisse, keine Ahnung, ob AVM wirklich "Scrum macht") im Moment sogar so weit, daß man die veröffentlichten Änderungen wohl gar nicht mehr selbst richtig (oder an einigen Stellen auch nur im Ansatz) testet und einfach den Stand irgendeines Sprints von Montag bis Donnerstag (hoch lebe die agile Softwareentwicklung) am Donnerstag nachmittag oder am Freitag in eine zu veröffentlichende Version einkübelt, als eine Art "continous delivery" ... sollen die Labor-Tester einfach schauen, wie sie damit klarkommen.
Wenn das wirklich jeweils nur "Details" wären, wo etwas nicht funktioniert, dann könnte man sagen: "Ist halt 'ne Beta-Version ...", aber einiges hat eben bei der jeweiligen Veröffentlichung noch nicht einmal das frühere Alpha-Stadium überwunden, weil mancher Fehler so augenfällig ist, daß der erste (unbefangene) Beobachter (und erst recht ein professioneller Tester) ihn sehen müßte oder zumindest sollte. Was bei Auftragsarbeiten ja noch funktionieren mag, weil die Umgebung ja meist trotzdem eine kontrollierte ist, wird bei der Entwicklung einer Firmware für einen Internet-Router (oder eine Infusionspumpe oder irgendetwas anderes an kritischer Infrastruktur) nach meiner Ansicht schnell fragwürdig. Zumindest bei Änderungen an sicherheitskritischen Teilen der Firmware sollte man auch als freiwilliger Tester einer Laborversion darauf bauen können, daß der Hersteller seine Hausaufgaben gemacht hat und da nicht plötzlich ein "Ups ... Entschuldigung für die Sicherheitslücke." notwendig wäre.
Zumindest steht ja bei der Labor-Version immer auch dabei:
avm.de schrieb:
Sie wurde von uns vor der Veröffentlichung in Standardumgebungen getestet, kann aber eventuell zu Fehlfunktionen führen.
- das ziehe ich bei genauerer Betrachtung der Firmware (Beispiel: 113.06.69-41875 -> etc/version -> DATE=04.11.2016 09:57:24 (Build) und erster Beitrag hier um 15:22 Uhr, da stand die dann schon zum Download bereit) dann schon in Zweifel.
Sicherlich wurde die in Standardumgebungen entwickelt - aber das, was beim "Zusammenkippen" zweier unabhängiger Entwicklungen dann am Ende herauskommt (in der Realität sind das sicherlich noch mehr (angeblich) unabhängige Entwicklungen), das wird wohl eher nicht mehr getestet (oder zumindest nicht sehr gründlich). Auch die Nummern bei den "Inhouse-Versionen" sprechen dagegen, daß da ein bestimmter Stand eingefroren und dann vor der Veröffentlichung als Labor-Version noch einmal getestet wird. Da ist dann das "kann zu Fehlfunktionen führen", was man als Tester sicherlich eher als "kann
in bestimmten Umgebungen zu Fehlfunktionen führen" verstehen würde, schon etwas dick aufgetragen.
Bei der 6490 zog sich das sogar bis in die freigegebene Release-Version. Wenn da bei der Entwicklung und bei den internen Tests mit einer "privaten" Version gearbeitet wird und es in der Firmware ganze Zweige gibt, die diesen privaten Versionen vorbehalten sind oder irgendwelche Spezialbehandlungen ausführen, dann muß man eben am Ende auch noch einmal nach dem Abschalten von "privat" sehr gründlich testen, bevor man so etwas auf die Kunden losläßt - zumindest dann, wenn man dem eigenen (verkündeten) Qualitätsanspruch nach wie vor gerecht werden will. Hier ändert sich aber (für mein Empfinden) das Hauptaugenmerk bei der Weiterentwicklung immer mehr von einer gut funktionierenden Firmware zur "Featuritis" und darunter leidet (meine Ansicht) die Qualität.
Irgendwie merkt man das dann sogar an der Qualität der Labor-Versionen und so wichtig unmittelbares Feedback auch sein mag ... wenn am Ende der Labor-Tester nicht mehr die Probleme in seiner speziellen Umgebung als freiwilliger Helfer für AVM austestet, sondern sich schon mit nicht funktionierenden "bread'n'butter"-Funktionen (wo man den Fehler sogar als Außenstehender findet und das schon bei AVM nicht funktioniert haben
kann in der veröffentlichten Form) herumärgern muß und das bei der (offiziellen) Notwendigkeit für Recovery, wenn er wieder auf eine besser funktionierende Version zurück will, spielt AVM nach meiner Meinung schon extrem mit dem Langmut der Kunden.
Im Gegensatz zu den Entwicklern und (hoffentlich) Testern bei AVM ist das nämlich nicht die "tägliche Arbeit" und da finde ich, geht AVM schon ganz schön verschwenderisch mit einer Ressource um, die auf den ersten Blick erst einmal nichts kostet.
Irgendwann fällt aber auch so etwas einem Hersteller mal auf die Füße - erste Stimmen werden ja auch hier ab und an schon mal laut. Meinetwegen soll man die Labor-Versionen dann wirklich "weekly builds" nennen - da weiß man wenigstens schon auf den ersten Blick, worauf man sich einläßt (das ist eben dann das, was gerade da ist - fertig oder nicht) und im Gegensatz zu einer Labor-Version (zumindest zu dem, was das mal sein sollte nach den Texten von AVM) ist es da dann normal, wenn mal etwas nicht funktioniert.
Vielleicht hat AVM ja deshalb aus dem "Labor" im Dateinamen bei der 113.06.69 Mitte September wieder ein "LabBETA" gemacht, aber diese Unterscheidung ist in der AVM-Webpräsenz gar nicht zu erkennen und auch bei einer öffentlichen Beta-Version - im herkömmlichen Sinne - sollte es ggf. zwar nicht oder falsch funktionierende Teilfunktionen, aber eben keine "unfertigen Baustellen" geben.