Re: [de-discuss] LibO RC 2 - weiterhin massive Probleme unter Windows

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+unsubscribe@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