Hallo, hust, gaaaanz früher zu Amigazeiten gab es mal nach alpha und beta auch noch gamma Versionen ;-) (Wink mit dem Zaunpfahl) ;-p
Gruß Matti Am 30.06.2015 um 20:12 schrieb Bjoern Michaelsen: > 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. > > -- 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
