[Gfoss] Sviluppo e manutenzione del software libero

[Andrea Peri]

No, mi autocorreggo.
Avevo letto male.

Te parli di fare un fork tmepraneo.

Che non e' chiaro che significhi temporaneo.

E comunque, si trattrebbe di pagare 2 volte.
Perche' te ipotizzi di finanziare sulla dev e poi rifinanziarlo anche della LTR.
Creando un fork temporaneo.

Mi pare una soluzione costosa a prescindere.

Se uno deve pagare per aggiungere la funzionalita' alla LTR perche'
deve pagare per metterlo anche nella versione DEV ?

A.



Il 4 agosto 2015 08:57, Andrea Peri <aperi2007 a gmail.com> ha scritto:
> Cia PAolo,
>
> intendi dire che se volessimo potremmo ottenere una evoluzione non
> sulla dev , ma bens' sul qgis 2.8.x ?
>
> E vedercela committata nel repo di qgis relativo alla versone 2.8 ?
>
> Ad esmepio volessimo il chesso' il 3D, potremmo finanziarlo per la 2.8
> senza ritrovarci con un fork in casa nostra che poi dobbiamo gestirci
> e che ci renderebbe differenti dal qgis ufficiale ?
>
> Non sto parlando di un fork , ma di un qualcosa aggiunto veramente al
> qgis 2.8 che poi uno avrebbe quando si scarica qgis 2.8.
>
> Questo e' importante da capire.
> Perche' fino a oggi ci era stato sempre raccontato che si doveva
> mettere per forza sulla dev.
>
> A.
>
>
> Il 4 agosto 2015 08:12, Paolo Cavallini <cavallini a faunalia.it> ha scritto:
>> Salve.
>> Grazie a tutti per l'interessante discussione. A mio modo di vedere, le
>> considerazioni fatte sono generali, e si applicano a tutto il software
>> libero a governance democratica, con piccole differenze.
>> Metto insieme i due threads, perché dal mio punto di vista sono
>> fortemente correlati:
>> * se qualcuno ha bisogno di una nuova funzione, la soluzione più
>> efficiente è implementarla nella versione di sviluppo; sta allo
>> sviluppatore prendersi la responsabilità di forniral in tempi certi, in
>> modo che sia inclusa nella versione desiderata
>> * se serve, si può finanziare il backporting della nuova funzione sulla
>> versione "stabile" (LTR), creandone un fork temporaneo; la valutazione
>> costi-benefici sta a chi finanzia
>> * i forks sono sempre possibili; in alcuni casi possono essere utili per
>> risolvere temporaneamente problemi pratici; raramente sono una buona
>> soluzione nel lungo periodo, ma esistono eccezioni
>> * è utile ed opportuno, per chi usa un software critico per il proprio
>> lavoro, dotarsi di opportuna assistenza e supporto, che guidino nella
>> decisione di quando e se aggiornare, e che possano risolvere prontamente
>> i problemi; vedo con sorpresa enti che usano un determinato software su
>> centinaia di postazioni, senza avere una adeguata forma di assistenza,
>> proprio come lo sarei per qualunque strumento (anche un parco auto, per
>> dire).
>> Saluti.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> _______________________________________________
>> Gfoss a lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
>> 750 iscritti al 18.3.2015
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------