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

Moin Harald,

danke für Deine ausführliche Mail. Den meisten Punkten stimme ich
zu. :)

Harald Köster wrote:
> (1) Eure Diskussion, ob und welche Fehler in welcher Version noch
> vorhanden oder auch korrigiert worden sind, ist ohne Nennung von
> entsprechenden Bug Reports kaum nachvollziehbar; finde ich jedenfalls.
> Nennt also bitte die Bug-Nummern, dann kann man entweder im Report
> selber oder auch im Wiki
> (https://wiki.documentfoundation.org/Releases/5.0.0/RC2) prüfen, ob die
> angesprochenen Bugs inzwischen korrigiert sein sollten.
Yep. Alles andere erzeugt nur unnötig Stress und Aufwand, zu einem
Zeitpunkt, wo eh schon alle gestresst & überarbeitet sind.

> (2) Man kann sicher nicht erwarten, dass bei einem neuen RC im
> gegenwärtigen Entwicklungsstand alle kritischen Bugs korrigiert sind.
> Was ich aber erwarten würde, ist, dass bei 'jeder' Alpha, Beta, RC vorab
> geprüft wird, ob alle Komponenten (Writer, Calc,..) mit den
> verschiedenen Betriebssystemen grundsätzlich bedienbar sind und damit
> testbar sind. Das heißt, dass Menüs, Kontextmenüs, Dialoge und
> Symbolleisten grundsätzlich funktionieren und sich die Anzahl der Crashs
> im Rahmen halten. Falls so ein Basistest negativ ist, sollte mMn eine
> Verteilung der Testversion geblockt werden. Da Dein Bug, Thomas mit
> einer bestimmten Datei auftritt, mag dies zwar für Dich sehr ärgerlich
> sein, heißt aber für mich erst mal nicht, dass LO grundsätzlich nicht
> bedienbar ist.
Yep. Der Basistest (oder 'Smoketest') sollte laufen, entweder
durchgeführt von demjenigen, der den jeweiligen Build macht, oder von
Robinson oder Sophie, sobald Pakete auf pre-releases hochgeladen
sind. Falls ihr sachdienliche Hinweise dazu habt, bitte auf der
internationalen QA-Liste diskutieren. Testcases sind in Moztrap.

Sowohl der Bug mit den duchsichtigen Menüs, noch der mit dem
Explorercrash wären derzeit durch Smoketests abgedeckt (und die Frage
ist, ob sie das sein sollten, denn die verfügbare Manpower dafür ist
begrenzt).

Darüber hinaus gibt es aktuell auf der dev-Liste eine Diskussion, was
die TDF sinnvoll bei weiteren automatischen Tests tun kann (was
manuellem Testen immer vorzuziehen ist, da der menschliche Aufwand nur
einmal anfällt).

> (3) Zum früheren Testen: Wer nur die deutschsprachigen Mailinglisten
> liest, erfährt in der Regel gar nicht, wann neue Versionen (Alphas,
> Betas, RCs) zum Testen verfügbar sind. Ich meine, zumindest auf der
> discuss-Liste sollte dies bekanntgegeben werden, damit potenzielle
> Tester überhaupt angesprochen werden können. Gleiches gilt für "bug
> hunting sessions". Und dies gilt natürlich auch für die discuss-Listen
> in anderen Sprachen. Vielleicht können den "Gelegenheits-"Testern auch
> ein paar Tipps an die Hand gegeben werden, damit die Tests qualitativ
> besser werden (Bsp.: Öffne eines von Deinen größeren Dokumenten und
> probiere alle Funktionen der Symbolleiste 'Zeichnen' aus.)
Florian, Cloph, da seit ihr prädestiniert - halte ich für einen guten
Vorschlag!

> (4) Ein weiterer Punkt ist im Augenblick die hohe Schlagzahl der neuen
> Testversionen im (fast) Wochenrhythmus. Für jemand, der im Leben noch
> andere Aufgaben hat, als LO zu testen, ist ruckzuck die gerade
> installierte RC-Version schon wieder veraltet und er muss neu
> installieren. Der Überblick über den Status der verschiedenen Bugs und
> Versionen kann dann schnell verlorengehen. Ich glaube, dass hier etwas
> mehr Ruhe für den Tester zum Analysieren von Bugs günstiger ist.
> Möglicherweise hilft dies auch den Entwicklern für die sorgfältige
> Behebung von Bugs, anstatt mit heißer Nadel einen Bugfix
> bereitzustellen. Eine gewisse Qualität der Testversion ist dann
> allerdings Voraussetzung (siehe Punkt 2), damit man weitertesten kann.
Da scheint hier aber kein Konsens zu herrschen - Thomas z.B. wollte
'sofort nach Bugfix' eine neue Version haben?

> (5) Den Begriff "release candidate" finde ich schon irreführend.
> Lediglich der letzte geplante RC ist ein ein echter RC. Die
> vorhergehenden RCs unterscheiden sich von den Betas dadurch, dass in
> ihnen die Systemintegration enthalten ist, sind in der Regel aber nicht
> für ein Release geeignet bzw. vorgesehen. Ich meine die ersten RCs
> sollten daher auch anders bezeichnet werden (eventuell Gammas oder
> Beta-Nummerierung fortsetzen). Siehe auch:
> https://de.wikipedia.org/wiki/Entwicklungsstadium_%28Software%29
Falls wir durch simples Umbenennen hier Wahrnehmung und Sorgen beheben
können, sollten wir das tun. ;)

Andererseits - die Aktiven hier sollten (jetzt) wissen, wie das
gemeint ist, und nach außen hin werden die Versionen ja nicht wirklich
beworben. Mir persönlich ist es daher herzlich egal, wie das Kind
genannt wird (und jede Umbenennung erzeugt Aufwände auf
Entwicklungs/Release-Engineering/QA-Seite).

> (6) Für mich ist es nicht transparent, wie der Freigabeprozess sowohl
> für Alphas, Betas, RCs (siehe Punkt 2) als auch für die echten Releases
> aussieht. Wer gibt frei und wird dieses überhaupt irgendwie
> dokumentiert? Wer entscheidet, ob eine neuer RC notwendig ist und warum
> dieser notwendig ist? Ich meine, mindestens QA sollte beteiligt sein und
> der jeweiligen Freigabe zustimmen. Die Freigabe sollte mMn auch
> dokumentiert und am Besten ins Wiki gestellt werden. Dabei sollten dann
> auch die kritische Bugs, soweit bekannt natürlich, aufgeführt werden,
> die für die jeweilige Freigabe durch die Freigebenden akzeptiert werden.
Das ist der einzige Punkt, wo ich Probleme sehe. Denn dazu bräuchte es
eine Authorität, die hart ja oder nein sagt, und bei einem nein das
Kunststück fertig bringt, Entwickler zu einem zeitnahen Fix zu
bewegen. Macht also den Graben zwischen QA und Entwicklung eher
größer...

Andersherum ist der Prozess derzeit konsensual im ESC (und dort werden
durchaus mal Releases verschoben), wobei dann gleichzeitig dort in
aller Regel Freiwillige gefunden werden, die den Fix übernehmen. Die
ESC-Calls sind im übrigen öffentlich, jeder ist herzlich eingeladen,
teilzunehmen (https://wiki.documentfoundation.org/Development/ESC)!

Viele Grüße,

-- Thorsten

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