[Gfoss] [SoC] modulo GRASS per il kriging - utenti cercasi
Markus Neteler
neteler a osgeo.org
Lun 18 Maggio 2009 16:38:57 CEST
2009/5/18 Paolo Cavallini <cavallini a faunalia.it>:
...
> Solo una cosa: io, dopo lungo rimuginio, sono *contrario* agli addons
> per grass. In effetti quasi sempre i moduli, che dovrebbero stare in
> addons come incubatore, mi sembra che ricevano pochissimo testing, e
> quindi rimangano incubati per sempre. Qual e' il problema nel metterli
> nel trunk (o, nel caso siano invasivi, in un branch)?
Per motivi vari serve una incubazione:
- mantenere la qualità di GRASS "main"
- evitare che sviluppatori nuovi mettono codice in trunk che
non è compatibile con la licenza di GRASS
- dare un testbed a quelli che sviluppano in gruppo senza
aprire trunk al "mondo"
- ...
Esempi:
- r.viewshed: bellissimo, velocissimo, ma con errore di precisione (vedi
test script nella cartella). Se lo mettessi in trunk oggi la gente
inizierebe
a sostituire il lentissimo r.los, ma poi accuserebbe GRASS di creare
dati sbagliati...,
- una serie di programmi non segue gli standards di GRASS come
descritti nei FILE SUBMITTING*.txt. Gli autori apparentemente non
hanno voglia di pulire il codice (nemmeno io),
- alcuni comandi sono senza documentazione,
- alcuni sono troppo specialistici (non vogliamo fare GRASS trunk
un "sourceforge" di roba non mantenuta). Bisognerebbe generalizzare
l'uso prima di metterli in trunk
Comandi messi in "main" di GRASS (vuol dire che c'è speranza):
- v.buffer
- v.delaunay
- r.horizon + r.sun
- ...
dopo la sistemazione dei loro problemi però.
Proposta/Soluzione:
- scrivere un meccanismo per integrare pacchetti di SVN-Addons tramite
script (vedi R extensions manager) - volunteers?
ciao
Markus
Maggiori informazioni sulla lista
Gfoss