Hallo Guido, On Sat, Dec 10, 2005 at 12:23:36AM +0100, Guido Ostkamp wrote: > Andre Schnabel <[EMAIL PROTECTED]> wrote: > > Wir finden dann freiwillige Tester, wenn wir aufmerksamkeit erzeugen > > .. Aufmerksamkeit erzeugen wir aber in der Regel erst dann, wenn > > wir releasen. > > aber dieses Statement bedeutet doch ohne Umschweife im Klartext > "Vergeßt die interne QA und laßt die Software beim Kunden reifen". > > Kann es das wirklich sein?
Nein. Du verwechselst da was. Auch wenn sich die freiwilligen Tester abrackern die Fehler zu finden ist die Zahl der freiwilligen Tester einfach zu gering um wirklich alle Fehler zu finden die irgendwie release-relevant wären. > Es macht doch ein Unterschied, *was* released wird. Man kann Public > Betas und Release Candidates öffentlich zur Verfügung stellen, um > Aufmerksamkeit zu erregen. Das passiert ja auch. Genau. Aber was nützen öffentliche Betas, Release Candidates (und auch die Milestones) wenn die keiner anschaut/keine Issues geschrieben werden? > Aber das sollte man so lange tun, bis eine ausreichende Qualität > erreicht ist und wenn es bis zum RC 25 dauert - wenigstens, was neue > Major-Releases betrifft. Du willst die neue Version in 3 Jahren haben? - Dann deinstalliere die 2.0, nutze die 1.1.5... Und höre Dir die ewig gleichen Beschwerden an (von Features die in der 2.0 drin sind, in der 1.1.5 aber fehlen, von Fehlern die schon längst gefixed sind, etc). > [...] > Ich bin jedenfalls sofort darüber gestolpert. Allein dieses Problem > (Issue #53634) wurde von 5 unabhängigen Leuten erkannt, und es gab > sogar eine rechtzeitige Korrektur, die man spätestens in einen 2.0.0 > RC4 hätte integrieren können. Ich habe das sogar nachdrücklich in > einem Kommentar angemahnt. So ziemlich jeder schreibt in einen Issue "der ist sooo wichtig, der muß unbedingt ins nächste Release!!!1!!1!" Auch wenn der Fehler bekannt war wurde er ganz klar falsch eingeschätzt. Kann passieren. Weder auf der qa-Liste noch auf der release-Liste wurde dieser Fehler erneut angesprochen. Dein Kommentar in allen ehren, aber die Planung des issues war ja schon vorher fertig (2.0.1), außerdem ist der Issue schon gefixed gewesen. Bei solchen Fällen schauen die Leute sich die Beschreibung, etc. nicht mehr so genau an. (Du hast ja auch eine "Standardantwort" erhalten) > Aber nein, es mußte ja unbedingt 2.0.0 released werden. Zu diesem > Zeitpunkt bestand doch gar keine Zeitdruck, die 2.0 war schließlich > keine Korrekturversion der 1.1.x Linie. Klar, rummeckern ist immer leichter als sich aktiv am QA-Prozeß zu beteiligen. Fakt ist daß der aktuelle Stand des codes jederzeit verfügbar ist (die Milestones), daß es Betas gab, daß es mehrere RCs gab. Trotzdem sind die Fehler halt keinem aufgefallen. Das Problem mit der Kapitelnumerierung fällt ja auch nicht auf wenn man nur versucht "funktionierts, funktionierts nicht" sondern erst wenn man sie wirklich intensiver nutzt. > > Das ergebnis auf die konkrete Frage: Release verschieben oder nicht > > war aber *sehr* eindeutig. > > > > D.h. nicht "irgendwer drückt die Releases durch" sondern die > > mehrheit der Community, die eine klare Meinung abgibt tut das. > > Ich will das Voting der dort abgebenen "Stimmen" nicht anzweifeln. > > Jetzt, nachdem 2.0.0 zu früh released wurde und das Kind quasi in den > Brunnen gefallen ist, will man natürlich möglichst bald Fixes zur > Verfügung stellen, wenn man sie schon erarbeitet hat - das kann ich > nachvollziehen. Nicht nur deswegen. > Nur macht das das aktuelle Image nach außen nicht viel besser. Es wird > dann nämlich erneut eine nach wie vor unausgereifte Version angeboten Klar. Weil Microsoft Office fehlerfrei ist. Weil Outlook[Express] oder der InternetExplorer oder Windows an sich fehlerfrei sind wenn sie released werden. Stört auch keine Sau. Daß massive Fehler jahrelang drin sind und nicht beseitigt werden stört da auch niemanden. Aber wehe man ist OpenSource und hat ein öffentlich einsehbares Bug-Tracking system, dann stürzen sich alle wie die Geier drauf. > und ein unabhängiger Beobachter wird sich weniger dafür interessieren, > wie die Differenz zum Vorgänger aussieht als vielmehr den > Gesamteindruck ggf. im Vergleich zu anderen Produkten wirken lassen. Wenns ein objektiver Vergleich wäre. Ist es aber nicht. > > Die Diskussion auf der Releases sagt mir aber, dass es immer > > schwerer wird, die Rlevanz der Fehler für die Anwender > > einzuschätzen. Und das wir immer schlimmer, je bekannter OOo wird. > > Nur .. das zu korrigieren, braucht einiges an Zeit (und imMoent hab > > ich noch nicth die zündende Idee, wie man es besser machen kann .. > > zumindest nicht mit den Mitteln, die uns zur Verfügung stehen). > > Generell braucht man mal eine klare Definition von > Standard-Testfällen, die 75-90% der von einem normalen oder > semiprofessionellen Anwender benötigten Funktionen abdecken. Ich denke > dabei etwa vom heimischen Gelegenheits-Briefchenschreiber, über die > Bürokraft bis etwa hin zur Diplomarbeit, um mal beim Writer zu > bleiben. Diese Fälle sollten dann noch gewichtet werden. Dir mag es entgangen sein, aber es gibt solche Testbeschreibungen. Es wird auch an zusätzlichen Testszenarien gearbeitet. Aber wiegesagt: Wenn da keiner Mithilft braucht man sich nicht darüber zu wundern daß nicht alle Fehler gefunden werden. > Je mehr basisnah eine Funktionalität ist, desto wichtiger ist sie > auch. Bsp: Wenn schon triviale Dinge wie Backspace oder automatische > Nummierungen nicht funktionieren, brauche ich mir um exotischere Dinge > wie gesperrte Schrift, Kapitälchen, Marginalien, Kerning, > Schusterjungen, 3D Effekte etc. erst recht keine Gedanken mehr zu > machen. Das ist nettes bla,bla (sorry). Das ist sowas von klar. Nur braucht es halt Leute die das testen und dann Issues schreiben und ggf. die Notwendigkeit eines Fixes darlegen wenn der Issue ein anderes Target bekommt. > Außerdem gibt es noch eine Reihe von Sonderfällen, etwa jetzt der > nahtlose Import und die Weiterbearbeitung von Dokumenten aus 1.1.5 in > OOo 2.0. > > In dem Zusammenhang verstehe ich z.B. zur Zeit überhaupt nicht, wieso > Import-Bugs wie in Issue #58777 beschrieben einfach auf Target OOo 3.0 > gelegt werden. Es muß auch irgendwer da sein der den Issue beheben kann. Programmierer sind rar und die anderen sind schon ausgelastet. > [...] > Auch bei der deutschen Online-Hilfe habe ich momentan nicht den > Eindruck, daß sich bei den verschiedenen RC's irgendwas ändert. Tut sich auch nicht. RCs sind was sie sind: Release Candidates. Da wird nicht mehr viel geändert. Das liegt aber auch daran wie das System mit den Übersetzungen funktioniert (externer Dienstleister, deshalb längere turnaround-Zeiten) > Bereits in Issue #56168 habe ich ein paar Sachen gemeldet "Bereits" ist relativ. Außerdem: >- die > dümpelt seit fast 2 Monaten immer noch als unconfirmed herum issues die unconfirmed sind schaut sich ein Entwickler wenn überhaupt nur zufällig an. Zusätzlich ist der genannte issue dem falschen Projekt zugeordnet. Hier zeigt sich halt wieder einmal daß die QA unterbesetzt ist. > [...] > Man kann aber keinen Fortschritt erkennen. Kommen Mechthilds & Co. > Änderungen denn gar nicht in einen 2.0.1 rein? Ja. Wenns im RC nicht drin ist, kommen die auch nicht mehr in die 2.0.1 > Wird diese Version mit der gleichen kaputten Onlinehilfe rausgehen wie > die 2.0.0? Ein paar Änderungen sind schon drin. ciao Christian -- NP: Soulfly - Soulfly (universal spirit mix) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
