La regola generale quando si fa il porting di un pacchetto open-source è quella di tenere traccia delle modifiche apportate per farlo costruire ed eseguire sul proprio sistema, e se si pensa che le modifiche sarebbero utili alla comunità in generale, di sottoporle ai manutentori del pacchetto. Di solito, questo ha anche il vantaggio di ridurre lo sforzo per le future porte dello stesso pacchetto.
Ho portato molti pacchetti software su VOS e OpenVOS, e di solito cerco di inviare le mie modifiche ai manutentori. Ma non sempre. Ecco perché.
1. Alcuni cambiamenti sono specifici dell'ambiente OpenVOS. Se faccio un cambiamento per aggirare una restrizione che si applica solo ad OpenVOS, allora non ha molto senso inviare questo cambiamento a monte. I manutentori generalmente rifiutano tali patch. Un esempio potrebbe essere il limite che le versioni precedenti alla 17.0 di OpenVOS hanno posto alle lunghezze dei nomi dei file.
2. Alcune modifiche potrebbero essere già state adottate in versioni successive del pacchetto open-source. Prima di inviare qualsiasi modifica, è sempre una buona idea controllare e vedere se qualcuno vi ha battuto sul tempo. Questo è particolarmente vero se è passato un po' di tempo da quando avete scaricato il codice sorgente originale. Non ha senso sprecare il tempo di tutti con modifiche stantie.
3. I cambiamenti sono in realtà in un prodotto diverso. Per esempio, ho recentemente terminato il porting di MySQL 5.1.48 su OpenVOS Release 17.1. Sono riuscito a fargli utilizzare la nuova funzione di collegamento dinamico su OpenVOS 17.1 apportando varie modifiche agli script di compilazione. Ma non ha senso inviare queste modifiche al team MySQL, perché le modifiche sono in realtà nel pacchetto autoconf, che viene mantenuto da un altro team. Il pacchetto MySQL è solo un utente di autoconf; non hanno alcun controllo su ciò che fa per una data piattaforma.
4. È passato troppo tempo tra quando ho preso una copia del pacco e oggi. Il problema qui è che un pacchetto open-source è un bersaglio in movimento. Mentre alcuni pacchetti sono abbastanza stabili e sono raramente aggiornati, altri sono in costante cambiamento. Ho passato 9 mesi a fare il porting di MySQL 5.1.48, perché è stato un lavoro part-time, e perché anche una volta che è stato portato, ho dovuto sincronizzarmi con il nostro processo interno di test e rilascio. Così, quando ero pronto a rispedire alcune patch al team di MySQL, queste erano già passate alla versione 5.5 (nel ciclo generalmente disponibile) e alla versione 5.6 (nel ciclo di sviluppo). Molte delle modifiche che ho dovuto apportare non si applicano più in modo pulito; in alcuni casi, i file sorgente sono stati rinominati o spostati in nuove directory. Potrei fare il lavoro per aggiornare completamente le patch alla versione attuale, ma è un lavoro molto impegnativo e, almeno a mio avviso, non vale lo sforzo che richiederebbe. La lezione per me è che avrei dovuto inviare i cambiamenti a monte non appena fossero stati stabili nella mia versione. Questo è ovviamente una sorta di richiamo al giudizio.
A volte, si possono fare tutti i passi giusti per inviare una patch specifica, ben scritta e ben disturbata, e i manutentori continueranno ad ignorarla o a rifiutarla. Questo può essere frustrante, ma non bisogna agitarsi per questo. Molti pacchetti open-source sono mantenuti da volontari, e quindi hanno un tempo limitato per occuparsi delle patch per piattaforme non comuni.
Nel caso del port OpenVOS di MySQL 5.1.48, ho scelto di aprire 5 specifiche segnalazioni di bug per questioni ben definite e indipendenti nel pacchetto MySQL che la mia ricerca mostra essere ancora presente nell'attuale release di sviluppo. Ho anche aperto una segnalazione di bug in modo da poter contribuire a tutte le nostre modifiche; un passo che è coerente con i termini della GNU Public License. In ognuno di questi casi, ho contribuito con una patch del codice sorgente che mostra le modifiche che ritengo appropriate per chiudere la segnalazione del bug. Spero che il team di MySQL integri le 5 modifiche specifiche che ho richiesto. Rappresentano problemi che potrebbero interessare altre piattaforme, non solo OpenVOS. Se siete curiosi di vedere le patch che ho inviato a MySQL, visitate http://bugs.mysql.com, cliccate su Ricerca avanzata e cercate i bug 44300, 44832, 60907, 60908, 60910, 60911, 60912 e 60913.
La porta OpenVOS di MySQL 5.1.48 sarà chiamata "MySQL for OpenVOS, Release 2.0" da Stratus, e sarà generalmente disponibile a breve, in concomitanza con la disponibilità di OpenVOS Release 17.1.