von KOMA » Fr 22. Jul 2011, 08:10
Vielleicht hilft es auch, einfach einmal ein anderes Repository zu verwenden, zu dem es eine stabilere Verbindung gibt. Jedenfalls hat das laut Google bei anderen Leuten geholfen. Eventuell gibt es da aber auch tatsächlich ein Problem in MiKTeX, dass es nicht erkennt, wenn ein Paket nicht korrekt heruntergeladen werden kann. Eventuell sitzt das Problem aber auch schlicht vor dem Computer …
Jedenfalls meldet man denselben Bug nicht mehrfach in einem Bug-Tracker, sondern vermeidet genau das. Stattdessen versucht man, den Bug möglichst genau zu dokumentieren und ggf. eine vorhandene Beschreibung sachlich zu verbessern. Bei MiKTeX kann man AFAIK irgendwelche Debug-Optionen setzen, damit eine zusätzlich Log-Datei o. ä. erstellt wird. Wenn solche Möglichkeiten vorhanden sind, sollte man auch diese nutzen.
Wenn ein Entwickler ein Problem nicht nachvollziehen kann, ist es logischerweise sehr schwierig, dieses zu beseitigen. Wenn dann außerdem die Informationen nur sehr wischi-waschi sind und auch auf Aufforderung (viele Bug-Tracker machen das automatisch) weiter nichts kommt, dann verliert der Entwickler auch die Lust an dem Problem und es kann sogar passieren, dass es geschlossen wird. Dann muss man es ggf. wieder öffnen und schauen, was man sinnvolles beitragen kann.
Wenn so etwas desöfteren vor kommt und solche Meldungen dann auch noch eher aus Anschuldigungen oder Gejammer bestehen, dann verliert der Entwickler insgesamt die Lust, immer wieder dieselben Hinweise zu geben. Das ist übrigens hier im Forum ganz ähnlich, wenn die Helfer immer wieder auf dieselben Grundlagen schon zum Stellen von Fragen hinweisen müssen.
Vorteilhaft bei einem Bug-Report ist auch, wenn der Melder signalisiert, dass er bereit ist, an der Beseitigung mit zu helfen und nicht nach zwei Tagen die Geduld verliert. Ich habe vor einiger Zeit einen Bug im Linux-ACPI-System gemeldet. Es hat über ein halbes Jahr gedauert und mich mehrere Wochen intensiver Arbeit gekostet, um immer wieder teilweise die gleichen Daten zu liefern, Dinge auszuprobieren, Kernel zu compilieren und zu installieren, Dokus zu Dingen zu wälzen, mit denen ich mich vorher nie beschäftigt hatte. Das begann bereits vor dem Bug-Report, indem ich mich u. a. aus anderen Bug-Report informiert hatte, welche Daten üblicherweise benötigt werden, und wie man die beschaffen kann. Am Ende wurde mein Einsatz damit belohnt, dass das Problem soweit beseitigt wurde, dass mein altes Notebook wieder bootet. Dass ich das zwischenzeitlich ersetzt hatte, spielte für mich keine Rolle. Schließlich bin ich nicht der einzige mit diesem Modell. Inzwischen verwende ich das Gerät sogar teilweise wieder u. a. zum Surfen (z. B. jetzt).
Ich schreibe das, um zu verdeutlichen, dass ein Bug-Report auch eine gewisse Verantwortung mit sich bringt, und man häufig selbst dafür verantwortlich ist, wie er behandelt wird und ob er zu einem nützlichen Ergebnis führt.
Achja: Man darf nicht erwarten, dass ein Bug-Report zu Begeisterung beim Entwickler führt. Die natürliche Reaktion ist: »Oh Mist, schon wieder!«. Niemand macht gerne Fehler. Man sollte das nicht dadurch verstärken, dass man die eigene Frustration auch noch an den Entwickler weiter gibt. Gut ist, wenn die natürliche Reaktion des Entwicklers am Ende »Prima, wieder ein Problem gelöst!« sein wird und nicht »Hoffentlich schreibt der nie wieder einen Bug-Report!« Das im Auge zu behalten, kann nicht schaden.
Vielleicht hilft es auch, einfach einmal ein anderes Repository zu verwenden, zu dem es eine stabilere Verbindung gibt. Jedenfalls hat das laut Google bei anderen Leuten geholfen. Eventuell gibt es da aber auch tatsächlich ein Problem in MiKTeX, dass es nicht erkennt, wenn ein Paket nicht korrekt heruntergeladen werden kann. Eventuell sitzt das Problem aber auch schlicht vor dem Computer …
Jedenfalls meldet man denselben Bug nicht mehrfach in einem Bug-Tracker, sondern vermeidet genau das. Stattdessen versucht man, den Bug möglichst genau zu dokumentieren und ggf. eine vorhandene Beschreibung sachlich zu verbessern. Bei MiKTeX kann man AFAIK irgendwelche Debug-Optionen setzen, damit eine zusätzlich Log-Datei o. ä. erstellt wird. Wenn solche Möglichkeiten vorhanden sind, sollte man auch diese nutzen.
Wenn ein Entwickler ein Problem nicht nachvollziehen kann, ist es logischerweise sehr schwierig, dieses zu beseitigen. Wenn dann außerdem die Informationen nur sehr wischi-waschi sind und auch auf Aufforderung (viele Bug-Tracker machen das automatisch) weiter nichts kommt, dann verliert der Entwickler auch die Lust an dem Problem und es kann sogar passieren, dass es geschlossen wird. Dann muss man es ggf. wieder öffnen und schauen, was man sinnvolles beitragen kann.
Wenn so etwas desöfteren vor kommt und solche Meldungen dann auch noch eher aus Anschuldigungen oder Gejammer bestehen, dann verliert der Entwickler insgesamt die Lust, immer wieder dieselben Hinweise zu geben. Das ist übrigens hier im Forum ganz ähnlich, wenn die Helfer immer wieder auf dieselben Grundlagen schon zum Stellen von Fragen hinweisen müssen.
Vorteilhaft bei einem Bug-Report ist auch, wenn der Melder signalisiert, dass er bereit ist, an der Beseitigung mit zu helfen und nicht nach zwei Tagen die Geduld verliert. Ich habe vor einiger Zeit einen Bug im Linux-ACPI-System gemeldet. Es hat über ein halbes Jahr gedauert und mich mehrere Wochen intensiver Arbeit gekostet, um immer wieder teilweise die gleichen Daten zu liefern, Dinge auszuprobieren, Kernel zu compilieren und zu installieren, Dokus zu Dingen zu wälzen, mit denen ich mich vorher nie beschäftigt hatte. Das begann bereits vor dem Bug-Report, indem ich mich u. a. aus anderen Bug-Report informiert hatte, welche Daten üblicherweise benötigt werden, und wie man die beschaffen kann. Am Ende wurde mein Einsatz damit belohnt, dass das Problem soweit beseitigt wurde, dass mein altes Notebook wieder bootet. Dass ich das zwischenzeitlich ersetzt hatte, spielte für mich keine Rolle. Schließlich bin ich nicht der einzige mit diesem Modell. Inzwischen verwende ich das Gerät sogar teilweise wieder u. a. zum Surfen (z. B. jetzt).
Ich schreibe das, um zu verdeutlichen, dass ein Bug-Report auch eine gewisse Verantwortung mit sich bringt, und man häufig selbst dafür verantwortlich ist, wie er behandelt wird und ob er zu einem nützlichen Ergebnis führt.
Achja: Man darf nicht erwarten, dass ein Bug-Report zu Begeisterung beim Entwickler führt. Die natürliche Reaktion ist: »Oh Mist, schon wieder!«. Niemand macht gerne Fehler. Man sollte das nicht dadurch verstärken, dass man die eigene Frustration auch noch an den Entwickler weiter gibt. Gut ist, wenn die natürliche Reaktion des Entwicklers am Ende »Prima, wieder ein Problem gelöst!« sein wird und nicht »Hoffentlich schreibt der nie wieder einen Bug-Report!« Das im Auge zu behalten, kann nicht schaden.