Gfoss -- Geographic Free and Open Source Software - Italian mailing list

Sviluppo e manutenzione del software libero

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

pcav

Sviluppo e manutenzione del software libero

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
_______________________________________________
[hidden email]
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

Re: Sviluppo e manutenzione del software libero

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 <[hidden email]> 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
> _______________________________________________
> [hidden email]
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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

Re: Sviluppo e manutenzione del software libero

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 <[hidden email]> 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 <[hidden email]> 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
>> _______________________________________________
>> [hidden email]
>> 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 àèìòù
> -----------------

pcav

Re: Sviluppo e manutenzione del software libero

Il 04/08/2015 09:01, Andrea Peri ha scritto:

> Te parli di fare un fork tmepraneo.
>
> Che non e' chiaro che significhi temporaneo.

Fino alla prossima LTR, o comunque fin quando serve al cliente.

> 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.

Certo: c'e' un costo extra, di cui vanno valutati costi e benefici in
funzione delle proprie funzionalita'.

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

Per assicurarne il mantenimento a lungo termine.

Saluti.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[hidden email]
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

Sandro Santilli

Re: Sviluppo e manutenzione del software libero

On Tue, Aug 04, 2015 at 09:12:37AM +0200, Paolo Cavallini wrote:
> Il 04/08/2015 09:01, Andrea Peri ha scritto:

> > Se uno deve pagare per aggiungere la funzionalita' alla LTR perche'
> > deve pagare per metterlo anche nella versione DEV ?
>
> Per assicurarne il mantenimento a lungo termine.

Esatto.

Ovviamente la somiglianza tra le due versioni DEV e LTR (non solo
in termini di API ma anche di disposizione e stile dei sorgenti)
modifica il costo di fornitura di due versioni "parallele".

Mantenere basso questo costo non e' esclusivo interesse di uno
specifico committente, ma di tutti coloro che usano il software.
La stabilita' serve a tutti, non solo agli enti pubblici e non solo
agli utilizzatori (e' noioso anche per uno sviluppatore, dover stare
dietro a continui cambiamenti, io ancora non mi sono ripreso
dall'aggiunta del prefisso "ST_" nelle funzioni PostGIS, per dire...).

--strk;
_______________________________________________
[hidden email]
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

Re: Sviluppo e manutenzione del software libero

In reply to this post by pcav

Ma la LTR (Long Term Release) dura 1 anno.

Quindi te stai dicendo che se uno finanzia una funzionalit'a pagandola
con soldi pubblici, essa sarebbe rilasciata entro 3 mesi sulla nuove
release, ma se la vuole su una release che al massm dura un anno, deve
pagare n costo extra che si puo' mediamente ipotizzare intorno al 50%.

Dopo di che' la spesa extra per la LTR viene persa perche' viene
rilasciata una nuova LTR su cui ci sarebbe la versione gia' pagata
precedentemente.

Senza contare che quando si passa alla nuova LTR nessuno garantisce la
continuita' con la precedente LT e quindi uno e' punto e a capo.

Pagare l'extra per la vecchia LTR significa solo posticipare il
problema di N mesi massimo 1 anno.

E' il classico "calcio al barattolo".

Basta aspettare...

Prima o poi queste cose si cominceranno a capire.

A.

>Certo: c'e' un costo extra, di cui vanno valutati costi e benefici in
>funzione delle proprie funzionalita'.

>> Se uno deve pagare per aggiungere la funzionalita' alla LTR perche'
>> deve pagare per metterlo anche nella versione DEV ?
>
>Per assicurarne il mantenimento a lungo termine.

Il 4 agosto 2015 09:12, Paolo Cavallini <[hidden email]> ha scritto:

> Il 04/08/2015 09:01, Andrea Peri ha scritto:
>
>> Te parli di fare un fork tmepraneo.
>>
>> Che non e' chiaro che significhi temporaneo.
>
> Fino alla prossima LTR, o comunque fin quando serve al cliente.
>
>> 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.
>
> Certo: c'e' un costo extra, di cui vanno valutati costi e benefici in
> funzione delle proprie funzionalita'.
>
>> Se uno deve pagare per aggiungere la funzionalita' alla LTR perche'
>> deve pagare per metterlo anche nella versione DEV ?
>
> Per assicurarne il mantenimento a lungo termine.
>
> Saluti.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html

nformica

Re: Sviluppo e manutenzione del software libero

In reply to this post by pcav

Scusate se la mia osservazione possa sembrare banale !

Ma non era più semplice, sia in termini di chiarezza per gli utenti finali (anche i meno esperti) sia in termini di risparmio di risorse, lasciare una sola linea di sviluppo di QGIS senza distinzione tra DEV e LTR ?
Anche a costo di avere nuove release con intervalli di tempo più lunghi; non è che non si ha un' aggiornamento ogni 3 mesi si muore !!

D'altra parte è quello che si fa per prodotti come GRASS, che distingue chiaramente le release stabili dalle "beta" e le RC.

Beh, sicuramente il gruppo di sviluppo di QGIS avrà avuto i suoi giusti motivi, non lo metto in dubbio.
Ma a me piaceva "più semplice" .

Ciao !
Nino

Silvio Grosso

Re: Sviluppo e manutenzione del software libero

Salve Nino,

nformica ha scritto:
> Scusate se la mia osservazione possa sembrare banale !
> Ma non era più semplice, sia in termini di chiarezza per gli utenti finali
(anche i meno esperti) sia in termini di risparmio di risorse, lasciare una
sola linea di sviluppo di QGIS senza distinzione tra DEV e LTR ?
Anche a costo di avere nuove release con intervalli di tempo più lunghi;
non è che non si ha un' aggiornamento ogni 3 mesi si muore !!

Bella domanda davvero ! :-)

Non sono uno sviluppatore di software ma per quanto ho potuto osservare personalmente utilizzando vari software open source negli anni credo che sia *molto* difficile stabilire quale sia la "ricetta" esatta per i rilasci del software :-)

In genere, specie per i software utilizzati a scopo lavorativo (pacchetti Office, GIS ecc), e' piuttosto difficile trovare gente volenterosa che abbia voglia di testare le versioni di sviluppo.
Questo fa si che il numero di problemi (bugs) scoperti sia spesso piuttosto ridotto finche' la versione stabile e' rilasciata: e qui che infatti saltano fuori i problemi piu' impensabili (ma ormai e' spesso troppo tardi...).
Krita, un software per disegno, invece ha invece moltissimi artisti che su Linux [1] lavorano direttamente sulla vesione di sviluppo pur di usufruire delle ultime funzionalita'.

Se il numero di sviluppatori e' limitato ovviamente avere una sola versione su cui lavorare cambia poco...
Con Gimp 2.6.x lo sviluppo era lentissimo in passato e c'era una sola versione su cui lavorare.
Attualmente, ci sono 2 versioni: 2.8.X, la stabile; 2.9.x quella di sviluppo con GEGL.
Parodossalmente, lo sviluppo sembra diventato ancora piu' lento [2] [3], sopratuttto perche' c'e' un solo sviluppatore (Michael Natterer) che ci lavora a tempo perso, nel suo limitato tempo libero...

Se infine consideri lo sviluppo di LibreOffice di cui e' stata rilasciata la nuova versione stabile proprio ieri (la 5) tutto funziona molto velocemente [4]. Ma qui ci sono molti sviluppatori a tempo pieno pagati da varie multinazianali (Red Hat, Canonical, Collabora ecc.).
Ti basta dare un'occhiata a questo documento [5] per constatare quanto hanno potuto lavorare sulla solidita' della nuova versione appena rilasciata.

Se leggi la mailing list internazionale degli sviluppatori di Qgis puoi vedere come ci siano state discussioni lunghissime e ripetute negli anni su quale sia IL modello di rilascio "migliore" da adottare...

Cordiali saluti

Silvio Grosso

[1] http://www.davidrevoy.com/article193/guide-building-krita-on-linux-for-cats
[2] https://git.gnome.org/browse/gimp/log/
[3] https://git.gnome.org/browse/gegl/log/
[4] https://wiki.documentfoundation.org/ReleasePlan
[5] https://people.gnome.org/~michael/blog/2015-08-05-under-the-hood-5-0.html