[Gfoss] Finanziare sviluppo di software libero (era: QGis Grass PlugIn 2.0)

Andrea Peri aperi2007 a gmail.com
Ven 31 Lug 2015 19:27:18 CEST


solo con i tuoi.

Vengo al tuo discorso.

Io non credo che un sistema del genere possa realmente funzionare su
un sistema come qgis.

 me pare il classico "calcio al barattolo" in termini informatici.

A fronte di un problema, rappresentato dal barattolo,
Il lavoro consiste nel dargli un calcio e spostare il problema piu' in la'.

Ovvero si fa' una infrastruttura in grado di fare certi tipi di tests
e poi salta fuori che presente l'infrastruttura , mancano i tests, che
vanno studiati e sempre tenuti aggiornati, e aggiornare i tests di una
struttura di autotesting non è molto facile, e il rischio e' che
sostanzialmente da una versione alla successiva di qgis vadano
sostanzialmente riscritti.
.
Cosa che poi finrebbe per divenire onerosa essa stessa. Piu' ancora
che non mettere in piedi l'infrastruttura stessa di test.

Del resto , e' nota in informatica, la legge del 20/80.

Ove mediamente il 20% del costo complessivo e' il costo di sviluppo e
l' 80% e' il costo di debug.
Per cui questa parte dei test potenzialmente potrebbe arrivare al' 80%
del costo complessivo.

In questo caso i tests sono anche piu' complessi perche' molto spesso
rivolti a verificare la parte della GUI, ovvero l'interfaccia grafica.


A.


Il 31 luglio 2015 18:55, Sandro Santilli <strk a keybit.net> ha scritto:
> On Fri, Jul 31, 2015 at 06:35:54PM +0200, Andrea Peri wrote:
>
>> Intanto ti segnalo che per qualche motivo che mi sfugge quando faccio
>> reply a tuoi messaggi la tua email non mi compare mai e devo
>> agiungerla a mano.
>
> Succede solo coi miei o anche con quelli degli altri ?
>
>> Te dici:
>>
>> >Non che non capisca il problema di cui parli, lo capisco molto bene,
>> >ma e' importante mettere i puntini sulle "i". Nessuno ha tolto nulla
>> >a nessun altro. Il software funzionante esiste ancora, e' ancora
>> >distribuibile, modificabile e ri-distribuibile da chiunque.
>>
>> Facciamo un esmepio concreto.
>>
>> Noi abbiamo commissionato una evoluzione su qgis a una ditta di cui
>> non cito il nome per non fare pubblicita'.
>>
>> Questa evoluzione ci e' stato detto che e' OBBLIGATORIO che sia fatta
>> su la qgis-dev e quindi entrera' in un prossimo rilascio di QGIS.
>> Non entrera' nella 2.8.x
>>
>> Su questosiamo tutti daccordo.
>
> Bene. Non vogliamo destabilizzare la release stabile...
>
>> Pero' te dici che io sono libero di usare la 2.8.x e nessuno m
>> cambiera' nulla sudi essa.
>
> Quella e' l'intenzione del branch stabile.
>
>> Ma se io io finanzio una evoluzione e la volgio sulla 2.8 perche' la
>> conosco e so' che mi va bene.
>> Te mi dici che non e' posssibile e previsto.E' prvisto per la versione
>> successiva.
>> Che peor' io ancora non conosco e quindi non so' se mi andra' bene.
>> Magari poi quando viene rilasciata scopro che gli manca un plugin che
>> a me serviva.
>>
>> E allora come la si mette ?
>
> Io non ho detto che non e' possibile.
> Assieme all'ultima versione 2.8.x hai ricevuto una licenza di modifica
> e distribuzione del codice. Hai tutto il diritto di modificare quella
> versione e pure di distribuirla con le modifiche che vuoi.
>
> Ovviamente non credo tu voglia mantenere un fork, ed e' quindi
> conveniente per te che la nuova funzionalita' sia anche inclusa nella
> prossima release "ufficiale". Ma nessuno ti vieta di includerla
> _anche_ in un fork diciamo "temporaneo" del codice.
>
>> te dici di finanziare un professionista che si occupi di verificare se
>> e' sabile.
>> Ma questo professinista, fino a che non e' rilasciata non credoche
>> potrebbe dirmi si va bene o no non va bene.
>
> Il codice e' disponibile _durante_ lo sviluppo, non solo al momento
> del rilascio. Io compilo qgis periodicamente (a volte giornalmente)
> e mi accorgo subito se (ad esempio) smette di compilare sul mio
> sistema.  Come me, molti altri sviluppatori fanno lo stesso.
>
> Inoltre, ci sono ora "robot" che lo fanno ad ogni commit, e riportano
> lo stato su una (o piu') pagine web. I robot non solo provano la
> possibilita' di compilare, ma lanciano anche tutti i test attualmente
> disponibili e verificano che funzionino tutti.
>
> Se la funzionalita' che si e' persa e' passata inosservata,
> evidentemente non aveva un test associato.
>
> Il professionista potrebbe occuparsi, tra le altre cose, di aumentare
> la copertura dei test automatici, partendo magari da quelli per le
> funzionalita' care al proprio cliente.
>
> --strk;



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


Maggiori informazioni sulla lista Gfoss