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