On Sat, Feb 25, 2012 at 7:01 PM, Andrea Aime <[email protected]>wrote:
> On Fri, Feb 24, 2012 at 7:21 AM, Paolo Cavallini <[email protected]>wrote: > >> Per chiarire: l'inclusione nel codice sorgente non e' mai automatica, e >> non e' certamente necessario essere sviluppatori di quel particolare pezzo >> di software per esserne certi. >> Le probabilita' comunque, IMHO vanno in modo decrescente con questo >> ordine approssimativo: >> sviluppatore di quel determinato pezzo>sviluppatore di quel >> progetto>sviluppatore di un altro progetto libero>non contributore di alcun >> progetto. >> E ovviamente la qualita' del codice e la governance del progetto hanno >> un'importanza molto rilevante. >> > > Concordo sulla gerarchia, in termini di probabilità generale, > completamente slegata dal singolo contesto. > Per fare un esempio che mi è familiare, GeoServer, una patch ha elevata > probabilità di essere integrata se: > Btw, il discorso che ho fatto vale per una patch che modifica la versione ufficiale del software. Ovviamente ci sono altre alternative: - fork del software. - fare un plugin che eviti completamente la comunità, o quantomeno il "core", rilasciato e gestito a parte Se l'uso è una-tantum, per un uno specifico e limitato nel tempo, è probabilmente ragionevole fare una versione specifica (fork) senza verifiche di qualità, basta che vada per lo specifico uso per cui è pensata (se poi un anno dopo si vuole quella funzionalità più qualcosa di nuovo che è nel software principale... ciccia) Un plugin a parte è un altro modo per evitare il costo/tempo di interazione (e integrazione) con la comunità degli sviluppatori. Il che va bene, ma chi accetta tale soluzione dovrebbe chiedersi chi ne fa manutenzione in lungo periodo: il contratto copre solo la produzione del nuovo plugin, o anche il suo mantenimento del tempo in uno stato funzionante? L'integrazione di una patch nel core è un po' diversa, una volta che è messa dentro l'onere di manutenzione non è solo su chi l'ha prodotta, ma anche su chi l'ha accettata (anzi, spesso chi ha prodotto la patch sparisce e rimangono solo gli svilupatori abituali a gestire quel nuovo blocco di codice, anche noto come "contributo hit and run"). Chiaro, questo non vuol dire che i "core developer" andranno come avvoltoi su ogni problema rilevato nel codice integrato nel core,ma senz'altro c'e' un occhio di riguardo che non può esserci nel codice gestito al di fuori del core (codice che gli sviluppatori abituali non conoscono e/o di cui non sanno l'esistenza). Ciao Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf -------------------------------------------------------
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012
