<pre>>Il giorno sab, 25/02/2012 alle 21.37 +0100, Andrea Peri ha scritto:
>><i> 
</i>>><i> Ma se hai fatto un fork del software chi ti rimette a posto la tua
</i>>><i> versione per i bachi che non attendono alla tua modifica , ma che
</i>>><i> erano in tale versione di software gia' in partenza ?
</i>>><i> Per me salvo rarissimi casi molto particolare l'idea che un cliente
</i>>><i> che commissiona una patch possa accettare che cio' provochi un fork
</i>>><i> del prodotto e' folle. 
</i>>
>Il discorso è interessante. Commissionare una patch una tantum senza che
>questa venga integrata upstream è il vero spreco di risorse. Ma un ente
>può anche avere il personale in grado di mantenere un fork interno.
><br><br>E' vero, infatti nel mio discorso io mi riferivo piuttosto al caso in cui un cliente<br>non è in grado di effettuare internamente e quindi si rivolge all'esterno.<br>Ovvio che anche le successive manutenzioni saranno all'esterno, da qui la scelta perdente di accettare un fork.<br>
Essa significa legarsi mani e piedi a chi ti ha fatto il fork e il tuo software comunque invecchierà come funzionalità e efficienza.<br><br>Invece, se lo sviluppo è interno, cioè il cliente è in grado di gestirsi autonomamente l'evoluzione,<br>
il fork non è una situazione cosi' penalizzante. Perchè esso non significa legarsi a quacuno esterno.<br><br>Questo pero' non vuol dire che le modifiche non debbano essere proposte alla community del prodotto.<br>
Anche se poi non vengono accettate. Non importa, restanoc omuqneu depositate nel sistema di ticket e quindi <br>qualcuno ne potrà trarre se vuole ispirazione per qualcosa di altro.<br><br>  >E in questo caso secondo me le cose stiano molto diversamente: con gli
>attuali sistemi di controllo versione (git e Mercurial, in sostanza) un
>fork è una cosa normale e quotidiana. E altrettanto normale è il
>rebasing, ovvero riportare le proprie modifiche personali "in cima" alla
>lista delle modifiche al software.
>
<a href="http://book.git-scm.com/4_rebasing.html">>http://book.git-scm.com/4_rebasing.html</a>
<a href="http://mercurial.selenic.com/wiki/RebaseExtension">>http://mercurial.selenic.com/wiki/RebaseExtension</a><br><br>So' di ditte che ancora usano il CVS e rifiutano perfino l'impiego del SVN.<br><br>>È ovvio che questo scenario non "finanzia i GIS liberi", ma al tempo
>stesso è possibile per la libertà stessa concessa dalla licenza.<br><br>E' il bello della licenza.<br>Resta il fatto che chi commissiona all'estenro deve evitare il fork perche' va contro il suo stesso interesse.<br>
<br></pre>-----------------<br>Andrea Peri<br>. . . . . . . . . <br>qwerty àèìòù<br>-----------------<br><br>