Bugs als Releasestopper - wie?

de-users
#1

Liebe Liste,

geht ja gerade wieder heiß her, die Diskussion, wann denn nun eine
Version rauskommen darf, ob sie dann fehlerfrei sein muss usw.

Was ich nicht kapiere, wie es manche Leute schaffen, Bugs zu
Releasestoppern zu machen, ich hingegen dazu anscheinend zu blöd bin.
Vermutlich muss ich nur dreist genug sein und bei
Importance "highest" und "blocker" anwählen, damit endlich jemand
aufwacht, der die Dinge vielleicht ändern kann.

Lange hat es z.B. gebraucht, bis endlich Formulare unter Base wieder
brauchbar waren. Der Bug besteht seit der 3.4 - die ganze Versionsreihe
durch und auch in der 3.5.0 . Erst jetzt konnte dies zur 3.5.1 behoben
werden. Andere Bugs, die ich für wichtig halte, habe ich mit dem Begriff
"major" versehen - weil ich dachte: Ist ja nur ein kleiner Zusatz,
sollte aber vor dem Release einer Version erledigt sein. Scheint aber
nicht behoben zu sein, wenn ich die Reaktionen so mitbekomme (fehlende
Voraussetzungen bei *.rpm-Paketen - libpng12 ...)

Für mich persönlich waren aller Versionen oberhalb der 3.3.* auf diese
Art Versionen, denen ich liebend gern den Stopper aufgedrückt hätte, da
ich eben viel mit Datenbanken arbeite. Erst bei der 3.5.1 werde ich
versuchen, Datenbanken wieder mit einer neueren LQ-Version zu bearbeiten.

Ich weiß, dass erst in jüngster Zeit überhaupt jemand dem
Datenbankumfeld wieder Beachtung schenkt. Dafür bin ich dankbar. Ich
wäre froh, wenn keine neuen Features hinzu kommen sondern erst einmal
die Bugs behoben werden, die u.a. mit den neueren Versionen
hinzugekommen sind - und die ich auch gemeldet habe.

Gruß

Robert

#2

Ich ergänze:

Was ich nicht kapiere, wie es manche Leute schaffen, Bugs zu
Releasestoppern zu machen, ich hingegen dazu anscheinend zu blöd bin.
Vermutlich muss ich nur dreist genug sein und bei
Importance "highest" und "blocker" anwählen, damit endlich jemand
aufwacht, der die Dinge vielleicht ändern kann.

Ich war jetzt einmal so dreist und habe eine meiner Meinung nach
eklatanten Fehler des 3.5.1 RC1 als Blocker tituliert. Mal sehen was kommt.
https://bugs.freedesktop.org/show_bug.cgi?id=46843

Kurzerklärung: Wenn in Base Abfragen erstellt werden und die Abfragen
eine Sortierung enthalten, so verschwindet beim erneuten Editieren der
Abfragen diese Sortierung. Da die GUI erst einmal keine Veränderung
wahrnimmt passiert nichts, solange nicht eine Änderung der Abfrage an
anderer Stelle erfolgt. Abgespeichert und schon wundert sich der
Datenbänkler über das Chaos, das so doch gar nicht beabsichtigt war.

Ist mir in 3.5.0 nicht aufgefallen, weil ich das für Datenbanken nur zu
ersten Tests benutzt habe. Jetzt bin ich gerade beim Handbuch Base bei
den Abfragen angelangt und stelle prompt unterschiedliche Fehler in
3.3.4 und schließlich auch in 3.5.1 RC1 fest - wobei die in 3.3.4 noch
erträglich sind (Reihenfolge der Sortierung wird durch die GUI
eigenwillig interpretiert - muss immer nach der Feldposition vergeben
sein), die in der 3.5.1 RC1 aber nicht hinnehmbar sind.

Gruß

Robert

#3

Hallo Robert,

geht ja gerade wieder heiß her, die Diskussion, wann denn nun eine
Version rauskommen darf, ob sie dann fehlerfrei sein muss usw.

Was ich nicht kapiere, wie es manche Leute schaffen, Bugs zu
Releasestoppern zu machen, ich hingegen dazu anscheinend zu blöd bin.
Vermutlich muss ich nur dreist genug sein und bei
Importance "highest" und "blocker" anwählen, damit endlich jemand
aufwacht, der die Dinge vielleicht ändern kann.

Da haben wir doch ein Teil des Dilemmas: Was ist nun eigentlich ein
"Showstopper"???

Wer legt die Kriterien dafür fest, welcher bekannte Fehler als
Showstopper und welcher Fehler als "kein Grund zur Sorge" einegstuft
wird?

Mir wäre es z.B. egal, wenn Präsentationen in Impress nicht mehr
laufen, weil ich sämtliche Präsentationen als PDF mache. Dafür
verwende ich aber exzessiv Draw! Ebenso bin ich bei einigen Dingen auf
Base angewiesen, wobei es mich in den Wahnsinn treibt, wenn ich eine
uralte Java-Version installieren muss, um (hoffentlich) meine kleinen
Datenbanken weiter benutzen zu können.

Es wäre für mich wirklich interessant, wie denn nun die ggf. noch
bekannten Fehler einer X.0-Version eingestuft werden.

Gruß,
Michael

#4

Hallo Michael,

geht ja gerade wieder heiß her, die Diskussion, wann denn nun eine
Version rauskommen darf, ob sie dann fehlerfrei sein muss usw.

Was ich nicht kapiere, wie es manche Leute schaffen, Bugs zu
Releasestoppern zu machen, ich hingegen dazu anscheinend zu blöd bin.
Vermutlich muss ich nur dreist genug sein und bei
Importance "highest" und "blocker" anwählen, damit endlich jemand
aufwacht, der die Dinge vielleicht ändern kann.

Da haben wir doch ein Teil des Dilemmas: Was ist nun eigentlich ein
"Showstopper"???

Wer legt die Kriterien dafür fest, welcher bekannte Fehler als
Showstopper und welcher Fehler als "kein Grund zur Sorge" einegstuft
wird?

Mir wäre es z.B. egal, wenn Präsentationen in Impress nicht mehr
laufen, weil ich sämtliche Präsentationen als PDF mache. Dafür
verwende ich aber exzessiv Draw! Ebenso bin ich bei einigen Dingen auf
Base angewiesen, wobei es mich in den Wahnsinn treibt, wenn ich eine
uralte Java-Version installieren muss, um (hoffentlich) meine kleinen
Datenbanken weiter benutzen zu können.

Du hast genauso wie ich Deine besonderen Präferenzen. Impress nutze ich
so gut wie nie - weil ich ganz gut ohne Präsentationen auskomme, nicht
weil ich ein anderes Produkt nutze.

Und mit der uralten Java-Version können wir noch so viel melden - das
ist ja nur Linux, und die Linuxer wissen sowieso, wie sie das Ding zum
Laufen bringen ...

Ich habe jetzt einen Testballon gestartet (siehe Mail 1.3., 21:11). Mal
sehen, ob mir jetzt erzählt wird, dass ich nicht den großen Hammer für
eine kleine Fliege rausholen soll. Für mich ist das eben keine kleine
Fliege, sondern ein Datenbankrisiko, was ich nie eingehen will - vor
allem, weil mir so etwas als momentaner Autor des Base-Handbuchs nachher
vorgehalten wird, dass ich davor doch bitte hätte warnen mögen.

Zur Zeit sieht es so aus, dass ich in der Einleitung für Base direkt vor
allen Versionen nach der 3.3.4 warnen muss, damit ich ein halbwegs
ruhiges Gewissen haben kann.

Gruß

Robert

#5

Hallo Robert,

habe deine anderen Mails gerade gelesen. Ich hatte mich für ein paar
Wochen beim Lesen ausgeklinkt, weil ich mit der ISO-Zertifizierung
unseres QM-Systems beschäftigt war (ich habe mir vor zwei Jahren den
Job als QMB "eingefangen"...).

Gerade aus dem Blickwinkel des QM gesehen: Qualität liegt ja in der
Erfüllung der Anforderungen. Aus eben diesem Blickwinkel sind dann die
Fragen interessant:

- Wessen Anforderungen sind hier gemeint (Spezifizierung der "Kunden")?

- Was für Ansprüche haben diese "Kunden" und wie wurden sie ermittelt?

- Welche Auswirkungen haben deren _ermittelte_ Ansprüche an das Produkt
  auf die weitere Entwicklung?

Ich weiß: Das Thema ist schon oft diskutiert und "beackert" worden,
aber die Fragen stellen sich ja regelmäßig wieder...

In diesem Falle kommt halt die Frage: Wer bestimmt, was als Showstopper
gilt? Wessen Anforderungen werden als Maßstab genommen und welche sind
dies?

Diese Frage stelle ich ohne jede Polemik! Es kann ja sein, dass ich
komplett andere Ansprüche stelle, als die Mehrheit der "Kunden". Oder
ich gehöre gar nicht zur "Zielgruppe", an die sich LO richtet. Dann
kann ich mich darauf einstellen: Wenn jetzt (krass ausgedrückt) z.B.
Draw in diesem Sinne als verzichtbarer Bestandteil eingestuft wäre,
müsste ich mich mal wieder näher mit InkScape befassen...

Es wäre nur schön, wenn sich da greifbare Kriterien abzeichnen, die
sich nachvollziehen lassen. Ich komme da nicht so recht hinter...

Gruß,
Michael

#6

Moin,

Es wäre nur schön, wenn sich da greifbare Kriterien abzeichnen, die
sich nachvollziehen lassen.

Eine Forderung, die ich spontan unterstützten würde.

Was ist an den offiziellen TDF-Kriterien unzureichend? Wie könnte man sie
verbessern?

http://wiki.documentfoundation.org/Release_Criteria/de

Gruß Nino

#7

Hallo Nino,

> Es wäre nur schön, wenn sich da greifbare Kriterien abzeichnen, die
> sich nachvollziehen lassen.

Eine Forderung, die ich spontan unterstützten würde.

Was ist an den offiziellen TDF-Kriterien unzureichend? Wie könnte man
sie verbessern?

http://wiki.documentfoundation.org/Release_Criteria/de

Erst einmal Dank für den Link. Da morgen der zweite Audit-Tag ist,
muss ich mich langsam mal wieder ins Bett begeben um morgen fit zu sein.

Trotzdem noch die Anmerkung:

Die Kriterien:

- die Applikation kann nicht installiert werden
- die Applikation startet nicht
- Daten gehen verloren
- die Applikation stürzt ab
- oder friert ein
- ein Sicherheitsloch
- Lizenzprobleme

sind ja eigentlich gut verständlich. Das Problem ist wohl:

- Unbrauchbare Funktion

Das müsste man ggf. mal näher untersuchen: Wann ist eine Funktion (und
was wird unter "Funktion" genau verstanden?) unbrauchbar?

Und dann käme die spannende Frage, des folgenden Textes:

   Auch einige normale Fehler können die oben genannten Symptome
   aufweisen. Die richtigen Blockaden müssen die folgenden Bedingungen
   erfüllen: ...

Da verbergen sich dann Stolpersteine, wie "...selten gebrauchte
Funktion...". Das könnten natürlich auch Funktionen sein, über die die
Tester nicht stolpern, weil sie bei den Testern nur als "selten
gebraucht" gelten und daher nicht im Fokus stehen. Wenn die Version
dann auf die "normalen User" losgelassen werden, machen sich Fehler
dort unangenehm bemerkbar.

Ich selber würde beim Testen z.B. nie über Makro-Fehler stolpern, da
ich Makros nicht mag. Wenn ich als keinen "Showstopper" finde, würde
ich bei einem Release Ärger mit den Leuten bekommen, die sogar
eingebaute Funktionen mit Makros nachbauen :wink:

Es ist wirklich nicht einfach,
Michael...

...der jetzt versucht, noch ein paar Stunden Schlaf zu finden...

#8

Robert Großkopf schrieb:

Was ich nicht kapiere, wie es manche Leute schaffen, Bugs zu
Releasestoppern zu machen, ich hingegen dazu anscheinend zu blöd bin.

Hallo Robert,

sicher nicht zu blöd, aber evenutuell zu aufgeregt? Deine Wortwahl lässt das vermuten. Versuche doch bitte, die Dir schon mehrfach nahe gebrachten Kriterien für brauchbare Bug-Reports zu berücksichtigen! DAS bringt die Sache voran, nicht die Wahl einer hohen Dringlichkeit. Blocker-Importance zeigt an, dass der Bug gemeinhin als Blocker akzeptiert wird - er wird nicht als Blocker akzeptiert, weil jemand die Vorwahl so eingestellt hat.

Ergänze im Report bitte fehlende Informationen:
- Erstelle kommentierte Screenshots (Aussagekräftiger Ausschnitt,
   in DRAW ergänzt) und hänge Sie an den Bug-Report (bei mehreren
   Dateien empfiehlt sich die Erstellung einer Zip-Datei, das ist
   übersichtlicher). Bei Veränderungen nach einem Update ist evtl.
   ein Screenshot aufgenommen beim Arbeiten mit einer alten
   Version hilfreich, dafür kann eine Portable Version oder
   eine Serverinstallation parallel installiert werden
   (<https://wiki.documentfoundation.org/Installing_in_parallel/de>
- Erstelle eine Schritt für Schritt-
   Anleitung (wirklich jeder Tastendruck und jeder Mausklick)
   wie das Problem reproduziert werden kann.
- Beschreibe ganz genau, was das Problem ist. Wichtig ist, ein
   nachvollziehbares Detail zu beschreiben, also nicht „alles
   sieht irgendwie anders aus“ oder "Sortierung im Eimer", sondern
   „Der erste Buchstabe des ersten Absatzes war bisher immer …. ,
   nun ...“ oder "nun werden die Datensätze in der ID-Reihenfolge statt
   in der nach Namen sortierten angezeigt"
   -- gib eine Quellenangabe, warum du das beobachtete Verhalten
      für falsch erachtest.
– Biete genaue Angaben zu
   -- Betriebssystem Version und Sprache, Gebietsschema
   -- LibO Version, Sprache der Bedienoberfläche, Gebietsschema
     --- Letzte LibO version, bei der Du die erwartete Funktion noch
         gesehen hast
   -- Einstellungen, die evtl. in Zusammenhang mit Deinem Problem stehen
      (Zugegeben, für einen Anfänger sehr schwer)
   -- Wie Du LibO startest und das Dokument öffnest (Jeder Mausklick ...)
   -- Alles, was Dir sonst noch durch den Kopf schießt

Mit vollständigen Angaben wird ein Bug (manchmal) gefixt, ehe er überhaupt zum Blocker werden kann, Lionel ist da wirklich schnell.

Grüße

Rainer

#9

Hallo Rainer,

Was ich nicht kapiere, wie es manche Leute schaffen, Bugs zu
Releasestoppern zu machen, ich hingegen dazu anscheinend zu blöd bin.

Hallo Robert,

sicher nicht zu blöd, aber evenutuell zu aufgeregt? Deine Wortwahl lässt
das vermuten. Versuche doch bitte, die Dir schon mehrfach nahe
gebrachten Kriterien für brauchbare Bug-Reports zu berücksichtigen! DAS
bringt die Sache voran, nicht die Wahl einer hohen Dringlichkeit.
Blocker-Importance zeigt an, dass der Bug gemeinhin als Blocker
akzeptiert wird - er wird nicht als Blocker akzeptiert, weil jemand die
Vorwahl so eingestellt hat.

Ich hake mich hier einmal ein, da das auf den eigentlichen
Releasestopper aus Base-Sicht seit der 3.4 ja wohl nicht zutrifft:
Unbrauchbare Formulare, weil Druckansicht statt Webansicht. Das wurde
von allen möglichen Leuten gemeldet; Duplikate also des Bugs, den Andre
Schnabel gemeldet hatte.

Mit diesem Bug hätte ich keine Version nach der 3.4.0 mehr rausgebracht.
Er ist nicht zum Stopper geworden. Und er war sicher hinreichend
beschrieben. In der 3.5.1 RC1 ist er behoben - da taucht der nächste
vorher nicht vorhandene Bug auf, der für mich diese Version ebenfalls
unnutzbar macht.

Dass meine Bug-Beschreibungen nicht ausreichend sind habe ich erst bei
der schnellen Beschreibung zu den nicht funktionierenden grafischen
Buttons (Formularelementen in Base-Formularen) festgestellt. Das
bedeutet aber nicht, dass nicht auch von anderen Leuten Bugs berichtet
wurden, zu denen meine dann plötzlich Duplikate waren, und die noch
immer existieren. Stopper 2 aus Linuxsicht, seit Anbeginn von LO
bekannt: JavaRuntime 6.22 ist die letzte, die mit Base vernünftig
funktioniert. Bei allen Nachfolgern kann ich beim Suchen durch Daten
eine Tasse Kaffee trinken gehen.

Natürlich finde ich das nicht gut und versuche etwas trotz meiner
rudimentären Englischkenntnisse zu ändern - ich ärgere mich nur über die
Äußerungen in einem meines Erachtens viel zu langen Thread zu "Mockup"
(was immer ein mockup ist ...), die solche Bugs als absolut
nebensächlich abtun.

Gruß

Robert

#10

Hallo und guten Morgen Robert Großkopf:

Hinweis siehe weiter unten:

Hallo Rainer,

Was ich nicht kapiere, wie es manche Leute schaffen, Bugs zu
Releasestoppern zu machen, ich hingegen dazu anscheinend zu blöd bin.

Hallo Robert,

sicher nicht zu blöd, aber evenutuell zu aufgeregt? Deine Wortwahl lässt
das vermuten. Versuche doch bitte, die Dir schon mehrfach nahe
gebrachten Kriterien für brauchbare Bug-Reports zu berücksichtigen! DAS
bringt die Sache voran, nicht die Wahl einer hohen Dringlichkeit.
Blocker-Importance zeigt an, dass der Bug gemeinhin als Blocker
akzeptiert wird - er wird nicht als Blocker akzeptiert, weil jemand die
Vorwahl so eingestellt hat.

Ich hake mich hier einmal ein, da das auf den eigentlichen
Releasestopper aus Base-Sicht seit der 3.4 ja wohl nicht zutrifft:
Unbrauchbare Formulare, weil Druckansicht statt Webansicht. Das wurde
von allen möglichen Leuten gemeldet; Duplikate also des Bugs, den Andre
Schnabel gemeldet hatte.

Mit diesem Bug hätte ich keine Version nach der 3.4.0 mehr rausgebracht.
Er ist nicht zum Stopper geworden. Und er war sicher hinreichend
beschrieben. In der 3.5.1 RC1 ist er behoben - da taucht der nächste
vorher nicht vorhandene Bug auf, der für mich diese Version ebenfalls
unnutzbar macht.

Dass meine Bug-Beschreibungen nicht ausreichend sind habe ich erst bei
der schnellen Beschreibung zu den nicht funktionierenden grafischen
Buttons (Formularelementen in Base-Formularen) festgestellt. Das
bedeutet aber nicht, dass nicht auch von anderen Leuten Bugs berichtet
wurden, zu denen meine dann plötzlich Duplikate waren, und die noch
immer existieren. Stopper 2 aus Linuxsicht, seit Anbeginn von LO
bekannt: JavaRuntime 6.22 ist die letzte, die mit Base vernünftig
funktioniert. Bei allen Nachfolgern kann ich beim Suchen durch Daten
eine Tasse Kaffee trinken gehen.

Natürlich finde ich das nicht gut und versuche etwas trotz meiner
rudimentären Englischkenntnisse zu ändern - ich ärgere mich nur über die
Äußerungen in einem meines Erachtens viel zu langen Thread zu "Mockup"

(was immer ein mockup ist ...),

Gem Recherche bei Wikipedia historische Entwicklung beinhaltet 'Mockup'
eine Reihe von deutschen Bedeutungen.
EDV-Leute geben dieser Bezeichnung den Inhalt wie 'Vorläufig, Diskussionsgrundlage'
Die Techniker (Architekten; Gebäude-Techniker, Maschinen-Konstrukteure, etc.)
würden für diesen Ausdruck verwenden: Vorentwurfs-Plan, Entwurfs-Plan, Ausführungs-
Plan. (Darin liegt auch ein Zeichen von Gründlichkeit)

Ich habe es auch hier erst lernen und die Begrifflichkeit mir aneignen müssen.

Mit freundlichem Gruß!
         JoLa

  Gruß Robert

#11

Robert Großkopf schrieb:

Ich hake mich hier einmal ein, da das auf den eigentlichen
Releasestopper aus Base-Sicht seit der 3.4 ja wohl nicht zutrifft:
Unbrauchbare Formulare, weil Druckansicht statt Webansicht. Das wurde
von allen möglichen Leuten gemeldet; Duplikate also des Bugs, den Andre
Schnabel gemeldet hatte.

Mit diesem Bug hätte ich keine Version nach der 3.4.0 mehr rausgebracht.

Hallo,

wenn's in irgendeinem Bug nicht weiter geht setze mich doch als CC dazu und Starte hier 'nen Thread mit der bug-Überschrift, evtl. kann ich helfen, das Verfahren zu beschleunigen.

Grüße

Rainer

#12

Hallo,

wollte nur sagen auch ohne mein zu tun hat das ganze nichts mehr mit dem Betreff zu tun.

Ich denke bei LO tut sich was, weil nicht nur ich mich abgewendet habe.
Nach der Installation von 3.5.0 haben einige generelle Sachen nicht mehr manchmal so ausgeschaut wie man es gewohnt war.
Bei mir war es das Modul Calc.

An Calc wird wahrscheinlich wenig bis gar nicht gearbeitet, weil da kann es ja wenig bis gar nichts neues geben.
Plötzlich haben sich aber Änderungen in, z.B. Impress, sich ohne das jemand genau weiss warum, auch hier ausgewirkt.

Meiner Erfahrung nach fehlt da einer der generell festlegt wie die Prozeduren, Funktionen überhaupt heißen dürfen oder der nichts anderes macht als den undankbaren Job die Dokumentation aktuell zu halten.
Bei mir kamen früher einige Bugs genau da her das ich abgestellt habe jedes mal das Rad neu zu erfinden weil wo anders hatte ich ja schon genau das selbe gemacht.
1. Gedanke für so was brauche ich ja die Zeit nicht aufzuwenden es zu Dokumentieren.
Habe bald festgestellt lieber doch, weil an einer Stelle im Programmpaket an die ich gar nicht gedacht hatte wurde doch aufgerufen.

Also habe ich erst mal nicht versucht das Alte zu verbessern sondern habe was neues nach den Kriterien des Alten erschaffen.
Nach einiger Zeit war dann der Alte Name Frei weil nicht mehr gebraucht.

Gruß
Christian