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

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