Hi Ulrich, *, 2012/11/5 Ulrich K. <ulrichka...@gmail.com>: > Robert Großkopf <robert <at> familiegrosskopf.de> writes: >> >> der Fehler ist bekannt und auch gemeldet: >> https://bugs.freedesktop.org/show_bug.cgi?id=55842
Der Bug ist nicht in der liste der "Most annoying bugs" (einem Meta-issue) gelistet und so nicht im direkten Fokus der Entwickler. > Leider sieht es nicht so aus. > Im Bugreport schreibt jemand, dass der Fehler in LibO-Dev 3.7.0.0.alpha0+ > noch da ist. > > Das verstehe ich nicht, Christian L. sagte doch, dass gemeldete und > nachvollziehbare Fehler in der nächsten Version, > also 4 Wochen später behoben werden. Das hat ja Stefan schon klargestellt... Gibt mehr Bugs/Feature wünsche als dass von den Entwicklern umgesetzt werden können, deshalb ist es wichtig, dass ihnen zugearbeitet wird, dass die wirklich wichtigen Bugs in den most-annoying-bugs zu den jeweiligen Releasen landen. Schlüssel dazu ist die Bug-Triage http://wiki.documentfoundation.org/QA/BugTriage enthält alle nötigen Infos. Je besser ein Issue geschrieben/aufbereitet ist, desto größer die Bereitschaft sich damit zu befassen. Wenn man erst 15 Minutern rumrätseln muss, was eigentlich Sache ist, dann geht man lieber weiter zum nächsten. Ebenso schaut man sich die als release-kritisch eingestuften Bugs vor den sonstigen an. Sprich: Wenn man wirklich will, dass ein Bug in der nächsten Version gefixed wird, dann braucht es Eigeninitiative. Dann muss man sich darum kümmern, dass der Bug entsprechend eskaliert wird. Entweder indem man seine "Beziehungen" spielen läßt (andere dazu nötigt die Arbeit zu tun) oder die nötigen Schritte selbst erledigt. Ist einem die eigene Zeit dafür zu schade, dann braucht man sich auch nicht nachträglich darüber beschweren, dass nichts passiert ist. Aber auch wenn ein bug in den most-annoying-bugs landet ist das noch keine Garantie dafür, dass er bis zum nächsten Release gefixed wird - das hängt dann von der Komplexität des Problems ab, und ggf. Seiteneffekten eines möglichen Fixes. Diese Seiteneffekte und sonstige Risiken lassen sich am besten vermeiden, wenn man den Bug zeitnah zu seiner "einführung" meldet. Sprich: Je früher der Bug gemeldet wird (mit der entsprechenen Information), desto höher die Chance eines Fixes. Im einfachsten ist z.B. einfach ein Rückgängigmachen des Commits, das das Fehlferhalten auftreten lässt. Das geht natürlich nur, wenn man eine entsprechende Codeänderung auch ausfindig machen kann → sprich je weniger Änderungen in Frage kommen, desto einfacher. Und auch wenn man die Änderung nicht komplett rückgängig macht, so hat man dann schon das Wissen, welcher Code dafür verantwortlich ist und muss nicht erst groß debuggen. tl;dr: * Bugs früh reporten (→ Interessierte (Dienstleister, QA-Freiwillige, tapfere Nutzer) sollten immer mal wieder die daily-builds testen und schauen, ob die für sie selbst kritischen Funktionen so funktionieren wie erwartet) * die reporteten Bugs kategorisieren, vorsortieren/aufarbeiten. Je weniger Zeit mit anderen Bugs vertrödelt wird, desto mehr Zeit bleibt für die "wichtigen". * die wichtigen Bugs entsprechend eskalieren, wenn ein Bug nicht in dem entsprechenden most-annoying-bug gelistet ist, dann ist er nicht im Fokus. Ja, das kostet Zeit und geht nicht automatisch. Aber wie schon geschrieben: Wenn es die eigene Zeit nicht wert ist, dann erst recht nicht die Zeit der Entwickler. ciao Christian -- Informationen zum Abmelden: E-Mail an users+h...@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/users/ Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
