Hi, On Tue, Jun 30, 2015 at 06:03:50PM +0200, Florian Effenberger wrote: > und vielleicht ist mein Verständnis von QA hier auch leider ein wenig > anders. Ich bin sehr skeptisch, ob es sinnvoll ist, gravierende Fehler, > die im RC1 festgestellt worden sind, egal ob sie das System zum Absturz > gebracht haben oder andere Fehlfunktionen verursacht haben, nicht erst > zu beheben, bevor ein RC2 erstellt wird (mag mal eine besondere Ausnahme > geben).
Es ist sinnvoll. Es finden sich alleine 19 Bugs im Tracker, bei denen die Entwickler dran gearbeitet haben, um sie im rc2 zu fixen: https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=PLEASETEST&list_id=546357&product=LibreOffice&query_format=advanced&status_whiteboard=target%3A5.0.0.2&status_whiteboard_type=allwordssubstr Allein um sicher zu gehen, das diese Bugs wirklich beseitigt sind, ist der neue RC sinnvoll. Auch die OSX/Linux-Tester Daeumchen drehen lassen, weil es Probleme auf Windows gibt, die sie nicht betreffen ist nicht hilfreich: Diese Tester koennen uns wertvolle Hinweise zu anderen Bugs geben (auch fuer Windowa). > Ich halte es jedenfalls nicht für sinnvoll, wenn die > freiwilligen Tester immer wieder über dieselben bekannten Fehler > stolpern. Grundsaetzlich gilt, wenn der Bug gemeldet, bestaetigt, triaged und priorisiert ist, aber noch keine Commitnachricht a la: https://bugs.documentfoundation.org/show_bug.cgi?id=44419#c28 vorhanden ist, ist es unwahrscheinlich, dass der Bug 'ausversehen' gefixt worden ist. > Ein Release Candidate ist nach meinem Verständnis eine Programmversion, > die grundsätzlich für das finale Release geeignet ist, so dass bei einem > neuen Release Candidate die wesentlichen Fehler des bisherigen Candidate > beseitigt sein sollten. Wortklauberei hilft uns hier nichts. Die Frage ist, was ist schlecht gelaufen, und wie koennen wir es besser machen. Zunaechst: Was ist z.Z. suboptimal gelaufen? Zwei Dinge: 1/ Die Systemintegration haben wir wie ueblich erst mit dem RC angemacht, und diesen Fehler erst jetzt entdeckt. 2/ Wir stellen erst bei Eintritt in die RC Phase fest, dass wir viele Fehler entdecken. 1/ ist natuerlich unangenehm, weil es ordentliches Testen eines Builds mit Systemintegration auf Windows erschwert. Das allein hilft uns allerdings nicht weiter. Die konstruktive Frage ist: Wie haetten wir diesen Fehler frueher finden koennen? Durch einen frueheren Build mit Systemintegration der auch von jemandem getestet wird. Evtl. koennte man also z.B. den alpha-Build mit Systemintegration bauen. Dabei gibt es aber zwei Probleme: a/ zu diesen Zeitpunkt ist der Fehler wahrscheinlich noch nicht im Produkt gewesen, waere also auch nicht gefunden worden. b/ Entscheidender: Selbst wenn: Wer haette diesen alpha-build mit Systemintegration den heruntergeladen und ausfuehrlich getestet? Wenn das keiner macht, hilft uns der tollste Komplettbuild nichts. Ich bin zuversichtlich, dass die Regression der Systemintegration bis zur Release gefixt sein wird. Allein, weil Regressionen einem Verursacher zuzuordnen sind, und das doch recht unangenehm waere fuer eben jenen. Zu 2/: Das Problem mit 'wir finden jetzt zu viele Fehler' ist kein Problem das wir 'nach Hinten' -- also ueber die weiteren RCs irgendwie loesen koennen. Das Problem muss vorher, also in den Alphas, Betas und auf dem Master geloest werden. Ansaetze dazu aus QA Sicht sind: a/ fruehes Testen: um so frueher ein Bug gefunden wird, um so mehr Zeit bleibt zum Fixen und um so eindeutiger laesst sich ein Bug einem Verursacher zuordnen, der sich dann dafuer verantwortlich zeigen wird. b/ gute Tiage/Bibisect/Bisect: Dies ist die Verschaefung bzw. das Nachholen, wenn a/ nicht geklappt hat. Mit bibisect laesst sich der Verursacher auch nachtraeglich noch gut eingrenzen. a/ kann man fuer die 5.0 natuerlich nicht nachholen. b/ schon. Entscheidend ist auch die psychologische Wirkung von a/ und b/. Wird beides auf einem bestimmten Niveau betrieben, werden jene Entwickler, die im Vergleich etwas nachlaessig mit dem Testen sind, vorsichtiger. Nur nebenbei bemerkt: Sollten die Zeitraeume zwischen den Releases vergroessert werden, wuerde die Situation noch extremer werden, weil das Produkt noch laenger 'unbeaufsichtigt' von Entwicklern veraendert wird, ohne das QA sich da viel drum schert. Entspechend schlimmer sieht es dann aus wenn die QA letztendlich dann den ersten Blick drauf wirft: http://devopsreactions.tumblr.com/post/48189077287/qas-first-look-at-new-build Zusammenfassung: Jetzt irgendwas an den Release Plan fuer 5.0 aendern zu wollen, wuerde einzig dafuer sorgen, dass wir: - noch weniger Testing haben - jede Menge Zeit von Entwicklern, QA und Release Engineers dafuer verwenden muessen, alles Neu-/Um-/Anderszukoordinieren. Das wird in keiner Weise zu einer besseren Release fuehren. Stattdessen muss der Ansatz sein, gleich nach der 5.0 den Master fuer 5.1 in Augenschein zu nehmen, Auffaelligkeiten frueh zu melden, so dass genug Zeit vorhanden ist, die Fehler einer Ursache zuzuordnen und zu beseitigen. Gerade ersterem ist durch ein paar Blicke mehr viel geholfen, weil 'jetzt gehts nicht, vor 2 Wochen gings noch' schon viel genauer ist als 'vor einem halben Jahr gings noch'. Bis zur 5.0 hat natuerlich diese Release den Fokus, zur Not mit Daily-builds ohne Systemintegration -- und zwar am besten mit klar umrissenen Bugreports. Ein 'weiterhin massive Probleme unter Windows' z.B. ist so allgemein gehalten, dass es dem Wichtigem im ersten Schritt, der Zuordnung an einen Verursacher oder Verantwortlichen kaum hilft. Abschliessend sei bemerkt, dass es nicht konstruktiv ist, hier die Entwickler in Sippenhaft zu nehmen: Natuerlich sollte ein Entwickler fuer _die_ Regressionen gerade stehen, die er oder sie verursacht hat. Wenn es allerdings eine Tendenz gibt Entwickler pauschal fuer Regressionen anderer zur Verantwortung zu ziehen, hilft das dem Projekt in keiner Weise. Am ehesten vergraetzt es jene, die auf Entwicklerseite fuer Verbesserungen sorgen wollen. Gruss, Bjoern -- Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org Probleme? http://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de Listenarchiv: http://listarchives.libreoffice.org/de/discuss/ Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
