Die allgemeine Faustregel bei der Portierung eines Open-Source-Pakets ist, dass man die Änderungen, die man vornimmt, damit es auf dem eigenen System gebaut und ausgeführt werden kann, im Auge behält und, wenn man glaubt, dass die Änderungen für die Gemeinschaft insgesamt nützlich sind, sie den Betreuern des Pakets vorlegt. Normalerweise hat dies auch den Vorteil, dass der Aufwand für zukünftige Portierungen desselben Pakets reduziert wird.
Ich habe viele Softwarepakete auf VOS und OpenVOS portiert, und ich versuche normalerweise, meine Änderungen an die Betreuer zu schicken. Aber nicht immer. Hier ist der Grund.
1. Einige Änderungen sind spezifisch für die OpenVOS-Umgebung. Wenn ich eine Änderung vornehme, um eine Einschränkung zu umgehen, die nur für OpenVOS gilt, dann hat es wenig Sinn, diese Änderung nach oben zu schicken. Die Betreuer werden solche Patches im Allgemeinen ablehnen. Ein Beispiel wäre die Beschränkung der Länge von Dateinamen in den Versionen vor 17.0 von OpenVOS.
2. Einige Änderungen könnten bereits in späteren Versionen des Open-Source-Pakets übernommen worden sein. Bevor Sie Änderungen einsenden, ist es immer eine gute Idee, zu prüfen, ob Ihnen jemand zuvorgekommen ist. Das gilt besonders, wenn es eine Weile her ist, dass Sie den ursprünglichen Quellcode heruntergeladen haben. Es macht keinen Sinn, die Zeit der anderen mit veralteten Änderungen zu verschwenden.
3. Die Änderungen befinden sich eigentlich in einem anderen Produkt. Ich habe zum Beispiel kürzlich die Portierung von MySQL 5.1.48 auf OpenVOS Release 17.1 abgeschlossen. Ich konnte es dazu bringen, die neue dynamische Linking-Funktion unter OpenVOS 17.1 zu nutzen, indem ich verschiedene Änderungen an den Build-Skripten vorgenommen habe. Aber es hat keinen Sinn, diese Änderungen an das MySQL-Team zu schicken, weil die Änderungen eigentlich im autoconf-Paket sind, das von einem anderen Team gepflegt wird. Das MySQL-Paket ist nur ein Benutzer von autoconf; sie haben keine Kontrolle darüber, was es für eine bestimmte Plattform tut.
4. Zwischen dem Zeitpunkt, an dem ich mir eine Kopie des Pakets besorgt habe, und heute ist zu viel Zeit vergangen. Das Problem dabei ist, dass ein Open-Source-Paket ein bewegliches Ziel ist. Während einige Pakete recht stabil sind und nur selten aktualisiert werden, unterliegen andere einem ständigen Wandel. Ich habe 9 Monate damit verbracht, MySQL 5.1.48 zu portieren, weil es eine Teilzeitarbeit war und weil ich mich auch nach der Portierung noch mit unserem internen Test- und Freigabeprozess abstimmen musste. Als ich also bereit war, einige Patches an das MySQL-Team zurückzuschicken, waren diese bereits auf Version 5.5 (im allgemein verfügbaren Zyklus) und Version 5.6 (im Entwicklungszyklus) aufgestiegen. Viele der Änderungen, die ich vornehmen musste, lassen sich nicht mehr sauber anwenden; in einigen Fällen wurden die Quelldateien umbenannt oder in neue Verzeichnisse verschoben. Ich könnte mir die Arbeit machen, die Patches vollständig auf die aktuelle Version zu aktualisieren, aber das ist eine Menge Arbeit und, zumindest meiner Meinung nach, nicht den Aufwand wert, den es erfordern würde. Die Lektion für mich ist, dass ich die Änderungen nach oben schicken hätte sollen, sobald sie in meiner Version stabil waren. Das ist natürlich eine Art Ermessensentscheidung.
Manchmal können Sie alle richtigen Schritte unternehmen, um einen bestimmten, gut geschriebenen, gut getesteten Patch einzuschicken, und die Betreuer werden ihn trotzdem ignorieren oder ablehnen. Das kann frustrierend sein, aber regen Sie sich nicht darüber auf. Viele Open-Source Pakete werden von Freiwilligen gepflegt, und so haben sie nur begrenzt Zeit, sich mit Patches für ungewöhnliche Plattformen zu beschäftigen.
Im Fall der OpenVOS-Portierung von MySQL 5.1.48 habe ich mich dafür entschieden, fünf spezifische Fehlerberichte für klar definierte, unabhängige Probleme im MySQL-Paket zu öffnen, die nach meinen Recherchen in der aktuellen Entwicklungsversion noch vorhanden sind. Ich habe auch einen Fehlerbericht eröffnet, damit ich alle unsere Änderungen wieder einbringen kann; ein Schritt, der mit den Bedingungen der GNU Public License vereinbar ist. In jedem dieser Fälle habe ich einen Quellcode-Patch beigesteuert, der die Änderungen enthält, die meiner Meinung nach angemessen sind, um den Fehlerbericht abzuschließen. Ich bin zuversichtlich, dass das MySQL-Team die 5 spezifischen Änderungen, die ich gefordert habe, integrieren wird. Sie stellen Probleme dar, die auch andere Plattformen betreffen könnten, nicht nur OpenVOS. Wenn Sie die Patches sehen wollen, die ich an MySQL geschickt habe, besuchen Sie http://bugs.mysql.com, klicken Sie auf Erweiterte Suche und suchen Sie nach den Fehlern 44300, 44832, 60907, 60908, 60910, 60911, 60912 und 60913.
Die OpenVOS-Portierung von MySQL 5.1.48 wird unter Stratus den Namen "MySQL for OpenVOS, Release 2.0" tragen. Sie wird in Kürze, zeitgleich mit der Verfügbarkeit von OpenVOS Release 17.1, allgemein verfügbar sein.
Unternehmen