Fixes sind nicht immer willkommen. Es muss oft viel Überzeugungsarbeit geleistet werden. Die folgenden Beispiele können übersprungen werden. Einfach bei
Die Moral weiter lesen.
Mal ein Beispiel:
Bis meine Build-Fixes für FreeBSD in ioquake3 aufgenommen wurde hat es ein paar Wochen Diskussion gebraucht. Das Problem - ich habe hier(7) Unterstützung mit eingebaut. Aus Gründen die ich immer noch für Unverständnis halte sind die Entwickler dagegen. Ich musste den Bug Report aufspalten. Obwohl ioquake3 seit meiner 1.36 Portierung aus dem Stand unter FreeBSD kompiliert wird, liefere ich die ioquake3 Quellen mit einem Patchset aus, um das Programm nahtlos in FreeBSD zu integrieren.
Ein anderes Beispiel:
In
ports/156901: [patch] devel/cmake breaks with CC containing spaces steckt eine Menge Arbeit und über 20 Tage Rechenzeit an
Regressionstests (mit Tinderbox) auf meinem AMD Quadcore.
Das ganze ist jetzt auf nach das 9.0 Release vertagt. Wenn es so weit ist, werde ich noch mal mindestens 10 Tage investieren müssen um wieder alles zu aktualisieren.
Ein Problem mit ldd ist schon
seit 2008 offen.
Der PR
ports/144164: make package-noinstall does not include rc.d scripts hat erstaunlich schnell zu einem Commit geführt. Die erste Version vom Patch hat bei 5 (von über 20000) Ports noch ein Problem verursacht. Und am Schluss kam tatsächlich noch ein
Folge-PR, weil alle Beteiligten ein Problem übersehen haben.
Die Moral des ganzen ist, dass Bugfixes eine Menge Arbeit für ein Projekt verursachen. Irgend jemand muss sich das genau ansehen und nachvollziehen ob es überhaupt ein Bug ist und den ggf. reproduzieren.
Viele Bugs werden erst einmal als unbedeutend betrachtet, ein Entwickler muss erst einmal von der spannenden Sache an der er eigentlich arbeitet weg gelockt werden.
Dann muss so ein Patch ausführlich getestet werden, selbst bei einem Exp-Run übersieht man gelegentlich noch Fehler.
Neue Features einbringen ist immer kritisch, monatelange Überzeugungsarbeit mit ungewissem Ausgang sind zu erwarten.
Mal ein paar Goldene Regeln:
- Niemals Bugfixes und zusätzliche Features mischen
- Regelmäßige Lebenszeichen überzeugen die Entwickler davon, dass ihr Projekt wichtig für Dich ist
- Verweise auf oder zitiere Dokumentation, ein bestimmtes Verhalten ist erst dann ein Bug, wenn es gegen die Dokumentation verstößt
- Wenn es keine Dokumentation gibt, nutze Analogien aus der Systemlandschaft und erkläre warum das aktuelle Verhalten nicht konsistent ist
- Frage nach, was gegen einen Commit spricht. Viele Entwickler lassen einen PR einfach schlafen, wenn Ihnen etwas an Deiner Lösung nicht passt. Hier ist Nachhaken angesagt, damit man seinen Fix anpassen kann